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CHAPTER  I 


INTRODUCTION 


There  is  a  need  for  a  facility  to  be  used  by  the  Air  Force  to  support 
2  2 

empirical  AFC  T  research.  The  facility  should  be  a  general-purpose, 
computerized  system  that  can  be  used  to  address  the  variety  of  research 
issues  listed  in  Table  1.  The  issues  are  summarized  briefly  in  Chapter  5 
and  discussed  in  detail  in  Volumes  n  and  III.  Tbe  purpose  of  the  present 
volume  is  to  present  a  high-level,  functional  design  of  a  system  that 
would  support  such  a  research  program. 

Figure  1,  which  has  been  reproduced  from  Volume  I,  illustrates  the  wide 

2  2 

range  of  contexts  within  which  AFC  T  occurs.  Many  of  the  issues  listed 
in  Table  1  are  appropriate  in  more  than  one  cell  in  Figure  1.  The  research 
facility  should  ideally  support  research  in  all  cells  in  the  figure,  but 
resource  constraints  and  simulation  technology  limitations  will  probably 
force  a  more  limited  scope. 

We  recommend  that  the  research  facility  support  team  research  involving 
2 

AFC  teams  comparable  in  size,  function,  and  configuration  to  the 

principal  members  of  an  AWACS,  CRC,  CRP,  or  TACC  team.  Such  teams 

consist  of  weapons,  surveillance,  command,  and  support  subteams.  If 

each  subteam  is  assumed  to  consist  of  three  individuals,  the  facility 

should  support  12  team  members.  Each  team  member  should  have  a 

console  that  is  functionally  similar  to  the  console  used  in  operational  or 
2 

planned  future  AFC  systems.  The  system  should  have  the  flexibility 
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to  allow  researchers  to  determine  the  number  and  capabilities  of  each 
operator  type  on  the  basis  of  research  requirements. 

2 

In  addition  to  the  AFC  team  members,  the  research  facility  should  include 
consoles  for  computer  operators,  researchers  observing  team  behavior 
and  performing  umpire  functions,  role  players  and  script  readers,  and 
software  developers  and  maintenance  personnel. 

The  team  behavior  should  occur  within  the  context  of  a  simulated  tactical 

scenario.  The  scenario  would  be  embodied  in  software  that  simulates 

tactical  events,  provides  imagery  and  tactical  information  to  exercise 

2 

controllers  and  AFC  team  members,  and  collects  and  analyzes  individual 
and  team  performance  data. 


OVERVIEW  OF  THE  RECOMMENDED  AFC2T2  RESEARCH  FACILITY 

The  recommended  research  facility  would  consist  of  three  primary 
subsystems: 

•  Hardware 

•  Personnel 

•  Software 

Figure  2  provides  an  overview  of  these  subsystems,  which  are  described 
briefly  in  the  following  paragraphs. 
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I 


Hardware 


The  system  would  be  driven  by  a  hardware  system  consisting  of  processing 
equipment,  operator  consoles,  and  other  peripheral  equipment  (Figure  3). 
The  processing  equipment  should  include  a  central  processing  unit  or,  if  a 
distributed  processing  architecture  is  followed,  a  number  of  minicomputers. 
We  recommend  a  distributed  processing  approach  for  two  reasons: 

•  The  system  can  be  procured  and  developed  incrementally 
over  time 

•  A  hardware  failure  in  one  component  is  not  as  likely  to 
cause  the  entire  system  to  fail 

Each  operator  console  would  consist  of  a  CRT  (or  equivalent)  display 
capable  of  presenting  dynamic  alphanumeric,  graphic,  and  simulated 
radar  information;  an  alphanumeric  keyboard;  a  function  keyboard; 
a  trackball  (or  equivalent  device);  and  voice  communication  gear. 
Communication  gear  should  include  headsets,  control  panels,  and 
automatic  voice  recognition /synthes is  devices.  All  consoles  should  be 
identical,  and  should  be  capable  of  supporting  the  diverse  classes  of 
users  listed  in  Figure  2.  In  addition  to  consoles  for  individual  operators, 
large-screen  displays  that  can  be  used  by  sets  of  operators  should  also 
be  provided. 

Peripheral  equipment  should  include  mass  storage  devices,  a  digitizer 
and  map  bug,  a  high-speed  printer,  a  device  for  the  output  of  hard  copies 
of  graphic  information,  and  all  required  interface  equipment. 
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Figure  3.  Hardware  Components  of  the  Recommended 
AFC2T2  Research  Facility 
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All  hardware,  including  operator  consoles,  should  be  commercial, 

off-the-shelf  equipment.  It  does  not  need  to  be  ruggedized  to  meet 

military  standards,  nor  does  it  need  to  match  existing  or  anticipated 
2 

C  equipment  exactly  in  terms  of  appearance  or  operating  characteristics. 
This  approach  should  minimize  acquisition  costs  and  delays,  and  reduce 
maintenance  problems. 

A  schematic  overview  of  the  recommended  system  is  presented  in 

2 

Figure  4.  The  figure  illustrates  a  case  in  which  there  are  nine  AFC 
team  consoles  and  four  consoles  for  exercise  controllers.  The  precise 
number  of  each  type  of  console  would  depend  on  the  details  of  research 
requirements. 

Personnel 


As  indicated  above,  the  research  facility  would  be  staffed  by  several 
types  of  users.  Figure  5  illustrates  the  major  categories.  Exercise 
designers  include  the  research  staff  and  personnel  from  external  agencies 
who  are  sponsoring  particular  exercises.  Their  primary  function  would 
be  to  specify  the  team  configuration,  research  variables,  and  background 
conditions  to  be  tested. 

Exercise  controllers  include  computer  operators  and  researchers.  The 
computer  operators  would  be  responsible  for  loading,  starting,  and 
monitoring  the  hardware  and  software  before  and  during  an  exercise. 

The  researchers  would  monitor  individual  and  team  behavior,  perform 
umpire  functions,  and  control  and  monitor  simulation  events  during  an 
exercise. 
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Role  players  and  script  readers  would  provide  voice  inputs  to  AFC” 
team  members,  and  respond  to  voice  outputs  from  the  team.  Script 
readers  would  read  statements  from  prepared  text  at  specified  times 
during  an  exercise.  Role  players  would  be  relatively  less  constrained, 
and  would  make  free  voice  inputs  as  appropriate  during  an  exercise. 

2 

The  AFC  team  members  would,  in  general,  be  military  personnel 
drawn  from  schools  or  operational  units  as  dictated  by  research 
requirements. 

The  software  developers  would  be  responsible  for  creating  and  modifying 
the  software  system. 

Maintenance  personnel  would  be  responsible  for  maintaining  the  hardware 
and  software  subsystems.  Hardware  naintenance  could  be  performed  by 
vendor  personnel  under  a  service  contract. 

It  is  likely  that  an  individual  would  perform  several  functions.  A 
researcher  would  be  likely  to  participate  both  in  the  exercise  design  and 
exercise  control  functions,  and  could  also  serve  as  a  script  reader  or 
role  player.  A  software  developer  could  also  act  as  computer  operator 
and  software  maintainer. 

The  staff  operating  the  research  facility  would  consist  of  a  mix  of 
in-house,  contractor,  and  military  personnel  in  ratios  determined  by 
research  needs. 
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Software 


The  software  subsystem  would  consist  of  the  modules  illustrated  in 
Figure  6.  An  operating  system  is  necessary,  but  its  characteristics 
are  relatively  unimportant  at  the  present  level  of  discussion.  It  should 
provide  adequate  programming,  editing,  and  debugging  capabilities  to 
expedite  the  software  development  process. 

The  personnel  support  modules  should  control  the  consoles  and  enable 
the  functions  of  all  participants.  These  modules  would  control  the 
display  of  all  information  on  all  consoles,  and  would  interpret  all 
operator  inputs.  The  modules  would  require  a  great  deal  of  flexibility 
so  that  they  could  be  reconfigured  to  support  a  variety  of  users. 

The  simulation  models  would  comprise  the  "driver  scenario"  for 

simulation  exercises.  The  function  of  the  models  would  be  to  generate 

2 

tactical  events  that  would  drive  the  behavior  of  the  AFC  team.  Each 
model  should  be  generalized  in  the  sense  that  parameter  values  can  be 
readily  modified  without  changing  the  structure  of  the  model  itself. 

A  generalized  sensor  model,  for  example,  would  contain  parameters 
for  range,  resolution,  and  target  location  accuracy.  The  same  model 
could  be  used  to  simulate  a  variety  of  radar  systems,  each  of  which  is 
characterized  by  a  different  set  of  parameter  values.  A  similar  strategy 
should  be  followed  in  designing  the  other  classes  of  models  listed  in 
Figure  6. 
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Figure  6.  Software  Components  of  the  Recommended  AFC  t 
Research  Facility 


The  driver  scenario  could  be  changed  radically  from  one  exercise  to 
another  by  changing  the  parameter  values  of  the  models.  The  values 
should  be  stored  in  a  simulation  data  base  that  can  be  accessed  and 
modified  conveniently  by  exercise  designers. 

The  simulation  models  would  also  draw  on  a  set  of  algorithms.  As  with 
the  simulation  data  base,  the  algorithm  base  should  be  readily  modifiable 
to  support  a  wide  range  of  research  requirements. 

Software  development  personnel  should  have  the  capability  of  preparing 
and  using  special-purpose  applications  programs  as  the  need  arises. 

ORGANIZATION  OF  VOLUME  IV 

Chapter  I  of  this  volume  has  presented  an  overview  of  the  hardware, 

2  2 

personnel,  and  software  subsystems  of  a  recommended  AFC  T  research 

facility.  Chapter  II  describes  its  functions  and  configuration  in  more 

detail.  Chapter  III  discusses  the  potential  impact  of  advanced  simulation 
2  2 

technology  on  AFC  T  programs.  Chapter  IV  evaluates  the  technical 
risk  associated  with  the  major  features  of  the  system,  and  Chapter  V 
summarizes  the  research  issues  that  the  system  could  be  used  to  address. 
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CHAPTER  n 


CONFIGURATION  AND  FUNCTIONS  OF  THE  RECOMMENDED 
AFC2T2  RESEARCH  FACILITY 


This  chapter  describes  the  configuration  and  functions  of  the  recommended 
2  2 

AFC  T  research  facility.  The  discussion  is  organized  into  three  sections 

•  Hardware 

•  Personnel 

•  Software 

The  discussion  is  intended  to  be  at  a  conceptual  level  that  can  be  developed 

subsequently  into  a  detailed  design  specification.  Such  a  specification 

would  require  the  acquisition  and  analysis  of  additional  information  about 
2 

AFC  team  functions,  the  tactical  environment,  computer  capabilities, 
and  empirical  research  plans.  The  foundation  for  detailed  research  plans 
is  provided  in  Volumes  II  and  III. 

HARDWARE 

The  recommended  hardware  system  would  consist  of  processing  equipment, 
operator  consoles,  and  other  peripheral  equipment.  Processing  and 
peripheral  equipment  are  discussed  briefly  below.  User  consoles  are 
discussed  separately  because  of  their  central  importance. 
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Processing  and  Peripheral  Equipment 


The  hardware  supporting  the  simulator  should  include  central  processing 
equipment,  mass  storage  media,  a  map  bug  and  digitizer,  high-speed 
printer,  a  device  for  the  output  of  graphic  information,  and  any  required 
interface  equipment.  The  central  processor  should  have  the  capacity  and 
speed  to  drive  the  scenario  events  at  a  rate  that  is  appropriate  for  the 
research/training  requirements  of  particular  exercises.  The  architecture 
of  the  system  is  largely  irrelevant  at  the  present  level  of  discussion, 
except  that  a  distributed  processing  system  may  be  well-suited  to  the 
research /training  applications  of  the  simulator.  A  relatively  powerful 
central  computer  that  generated  simulation  events  and  controlled  the  flow 
of  information  could  communicate  with  less  powerful  computers  that 
handled  display  requirements  and  operator  interaction  at  individual 
consoles,  for  example.  This  approach  would  have  the  advantage  of 
allowing  the  facility  to  be  developed  and  tested  incrementally,  and  it 
would  also  reduce  the  probability  that  a  single  hardware  failure  would 
cause  the  entire  system  to  go  down. 

The  system  should  include  standard  mass  storage  equipment  for  recording 
all  software  and  performance  data. 

A  map  bug  and  digitizer  should  be  provided  for  the  entry  of  graphic 
information.  Map  contours,  the  initial  distribution  of  Blue  and  Bed 
forces,  and  other  data  would  be  entered  through  this  channel. 
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Output  devices  should  include  a  high-speed  printer  and  a  device  for  printing 
graphic  data.  The  printer  would  be  used  for  software  development  and 
maintenance  purposes,  as  well  as  for  printing  performance  data.  The 
other  devices  could  be  a  digital  plotter  or,  preferably,  a  photocopy  unit 
that  would  reproduce  the  contents  of  a  specified  CRT  display  screen. 

This  would  enable  the  reproduction  of  graphics  files  and,  more  importantly, 
of  performance  data.  A  plot  of  the  relative  paths  of  targets  and  intercep¬ 
tors  could  be  generated  and  distributed  to  trainees  for  feedback,  for 
example. 

All  hardware  should  be  standard,  off-the-shelf  commercial  equipment. 
There  appears  to  be  no  compelling  reason  to  invest  in  militarized, 
ruggedized  equipment  for  the  research  applications  that  are  envisioned 
for  the  simulator.  The  use  of  standard  commercial  equipment  should 
ease  acquisition  and  maintenance  problems. 

User  Consoles 


The  recommended  system  should  include  several  consoles.  The  precise 

number  would  depend  on  resource  constraints  and  research  requirements, 

but  the  goal  is  to  provide  a  console  for  each  of  the  key  members  of  an 
2 

AFC  team  comparable  to  an  AWACS,  CRC,  CRP,  or  TACC.  This 
would  include  weapons,  surveillance,  command,  and  selected  support 
subteam  members  (recorders,  tellers,  plotters,  radio  operators,  radar 
technicians,  computer  technicians). 
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2 

In  addition  to  the  AFC  team  members,  other  categories  of  system  users 
will  also  require  consoles  (See  Figure  5).  Because  the  relative  proportion 
of  each  category  will  vary  widely  across  research  programs  and  across 
phases  within  a  program,  we  recommend  that  the  physical  configuration 
of  consoles  remain  constant  for  all  users.  Identity  among  the  consoles 
would  allow  the  mix  of  personnel  to  be  changed  to  meet  varying  research 
requirements  and  it  would  also  reduce  system  development  and  maintenance 
costs.  Modification  of  the  functions  of  a  console  to  adapt  to  the  needs  of 
specific  users  would  be  done  by  substituting  software  modules  and 
subroutines.  User  consoles  should  include  the  following  components: 

•  Display 

•  Keyboard 

•  Voice  communication  gear 

In  addition  to  these  components,  large-screen  displays  would  present 
information  to  multiple  users.  Each  component  is  discussed  below. 

Display — The  console  display  should  be  capable  of  presenting  simulated 
radar  imagery,  graphics,  and  alphanumerics .  As  currently  envisioned, 
a  CRT  screen  would  present  "white"  imagery  on  "black"  background 
as  is  the  case  with  most  current  and  anticipated  systems  (black  and  white 
are  intended  to  mean  the  two  tones  used  on  displays  with  light  imagery  on 
a  dark  background).  The  intensity  of  the  display  should  be  adjustable. 

In  addition,  the  capability  for  reverse  video  (dark  patterns  on  a  light 
background)  and  color  should  be  considered  as  growth  options  for 
expanding  the  range  of  research  issues  that  can  be  addressed. 
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Required  display  capabilities  do  not  vary  significantly  across  control. 

surveillance,  and  battle  staff  operators.  The  display  should  be  capable 

of  presenting  graphic  and  alphanumeric  information.  Graphic  information 

would  include  simulated  radar  returns,  map  boundaries  and  terrain 

features,  aircraft  track  identification  data,  and  any  other  information 

deemed  appropriate  by  the  researcher.  If  the  simulator  is  to  be  used  to 
2 

simulate  older  C“  systems,  the  display  should  have  the  capability  of 

representing  both  "raw"  and  synthetic  radar  imagery.  However,  since 

2 

recent  and  anticipated  C  systems  present  synthetic  imagery  exclusively, 
we  feel  that  the  capability  to  simulate  raw  returns  is  not  required. 

2 

Alphanumeric  information  on  an  AFC  team  member's  display  should 
include  that  which  would  normally  be  provided  during  a  mission: 
operator  data  entries  and  commands,  error  messages  and  warnings  to 
the  operator,  and  any  feedback  that  is  peculiar  to  the  research  setting. 
Feedback  would  be  generated  either  automatically  by  the  computer  or 
manually  by  simulator.  Although  upper-case  characters  would  be  suitable 
for  most  applications,  lower-case  capability  should  not  be  ruled  out. 

2 

Display  requirements  for  AFC  team  support  personnel  are  a  subset  of 
the  requirements  for  weapons,  surveillance,  and  command  positions. 
Alphanumeric  and  some  graphics  capabilities  will  be  necessary  for 
recorder-teller-plotter  functions  and  for  functions  comparable  to  those 
performed  by  an  AWACS  airborne  radar  technician  or  communications 
operator.  Such  support  personnel  work  primarily  with  tabular  displays, 
and  do  not  view  radar  or  other  graphic  imagery. 
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All  operator  displays,  except  perhaps  the  displays  for  AFC"  support 

personnel,  should  be  able  to  present  digitized  map  contours.  The 

researcher  would  define  and  enter  relevant  contours  (geopolitical 

boundaries,  airspace  boundaries,  road  networks,  SAM  perimeters, 

etc.  ).  To  the  extent  that  such  capabilities  are  appropriate  for  simulated 
2 

AFC  team  operations,  team  members  should  also  be  able  to  enter  and 
modify  graphics. 

Some  cost  savings  may  be  realized  by  using  less  expensive  alphanumeric 
displays  for  operators  who  require  no  radar  imagery  or  graphics.  This 
approach  is  not  recommended,  however,  because  of  the  flexibility  that 
is  required  for  the  wide  range  of  research  issues  that  must  be  addressed. 

It  may  be  necessary,  for  example,  for  all  displays  to  support  weapons 
functions  for  one  research  project. 

Keyboard- -  The  keyboard  should  be  partitioned  into  three  major  components: 
an  alphanumeric  keyboard,  a  function  keyboard,  and  a  track  ball.  The 
alphanumeric  keyboard  should  be  in  standard  QWERTY  format.  It  would 
be  used  by  all  users  to  enter  data  and  commands.  The  precise  nature  of 
the  commands  and  data  would  vary  as  a  function  of  user  category.  It  may 
be  desirable  for  the  keyboard  to  include  a  separate  numeric  keypad. 

The  function  keyboard  should  consist  of  a  set  of  keys  to  be  used  by  an 
operator  to  access  console  functions  directly.  Examples  of  functions 
that  are  relevant  to  weapons  and  surveillance  operators  are  listed  below: 

•  Change  display  scale 

•  Compute  range  and  bearing  between  two  points 
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•  Offset  the  display  center 

•  Change  radar  mode 

•  Compute  intercept  geometry 

•  Find  altitude 

•  Attach  labels  to  aircraft  symbology 

•  Create  graphics 

A  complete  list  would  result  from  the  consolidation  of  console  functions 

2 

lists  for  current  and  future  AFC  systems.  Simulator  control  personnel 
would  have  a  different  set  of  functions. 

Many  console  functions  exist,  but  the  number  of  function  keys  may  probably 
be  reduced  to  20-30  by  organizing  functions  hierarchically.  Then  a 
top-level  function  could  be  accessed  by  selecting  a  function  key  and  the 
operator  would  select  from  subordinate  functions  appearing  in  a  reserved 
area  of  the  display  screen  (a  menu).  An  alternative  to  the  menu-selection 
approach  would  be  for  a  function  key  to  initiate  a  dialog  related  to  a  class 
of  functions.  The  operator's  input  during  the  dialog  would  determine  the 
nature  of  the  function  that  was  invoked. 

The  function  keys  should  have  some  provision  for  providing  visual  feedback 
to  the  operator.  Two  methods  for  doing  this  would  be  to  embed  lights  in 
the  key  surface  or  to  use  a  backlighting  system.  In  either  case,  the 
lighting  logic  should  indicate  which  of  three  possible  states  the  key  is  in: 
not  available,  available  but  not  in  use,  or  available  and  in  use.  Because 
a  common  keyboard  format  for  all  users  is  recommended,  not  all  keys 
would  be  functional  for  any  given  user  in  all  research  programs.  The 
lighting  logic  should  indicate  which  keys  are  available  for  use. 
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Function  keyboard  labels  should  clearly  identify  the  function  that  will  be 
initiated  by  each  key.  Whenever  possible,  the  label  should  be  a  single 
imperative  verb  that  characterizes  the  function  in  the  operator's  terms. 
The  labels  should  be  readily  modifiable.  It  should  be  convenient  to 
remove  all  labels  for  weapons  directors,  for  example,  and  replace  them 
with  labels  for  script  readers. 

A  track  ball  (or  equivalent  device)  should  be  provided  to  control  a  cursor 

in  the  imagery  area  of  the  display.  Functions  requiring  track  ball  input 

include  range /bearing  calculations  and  display  offset  functions.  The 

performance  characteristics  and  physical  dimensions  of  the  trackball 

2 

should  be  similar  to  track  balls  on  existing  AFC  systems.  The  track 

ball  would  be  used  mainly  by  weapons,  surveillance,  and  battle  staff 

2 

members  of  simulated  AFC  teams.  System  support  personnel  would 
use  track  balls  only  occasionally,  if  at  all. 

Voice  Communication  Gear--Each  user  console  should  include  a  voice 

communication  set  consisting  of  a  headphone,  control  panel,  and 

automatic  voice  recognition /synthesis  devices.  The  function  keys  on 

the  control  panel  should  be  reprogrammable  by  the  research/instructor 

staff  to  set  up  the  communication  network  that  is  appropriate  for  each 

research /training  situation.  Nodes  in  the  voice  network  should  include 
2 

the  AFC  team  members  and  exercise  control  personnel,  and  the 
communication  pathways  among  the  participants  should  be  modifiable 
to  meet  research  requirements. 
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In  addition  to  human  participants  in  the  voice  network,  it  is  possible  that 
the  computer  system  could  also  participate  to  some  extent  in  voice 
communication.  This  would  be  possible  if  voice  recognition  and  synthesis 
were  included  in  the  system.  We  recommend  that  such  capabilities  be 
provided. 

Large -Screen  Pis  plays --The  function  of  large-screen  displays  would  be 

to  present  tabular  situation  displays  to  exercise  control  personnel  and 
2 

to  AFC  team  members.  One  reason  for  including  such  displays  would 
be  to  automate  labor-intensive  jobs,  thus  reducing  the  number  of  personnel 
required  for  implementing  a  simulation  exercise.  Another  reason  would 
be  to  provide  a  testbed  for  evaluating  large-screen  displays  for  tactical 
use.  The  number  of  large  displays  would  be  less  than  the  number  of 
consoles,  and  all  users  should  be  able  to  see  all  displays. 

PERSONNEL 

Figure  5  illustrates  that  several  categories  of  users  would  interact  with 
the  recommended  system.  The  purpose  of  the  present  section  is  to 
outline  the  major  functions  to  be  performed  by  each  category  of  user. 

The  list  of  functions  is  not  complete  for  any  category,  but  it  characterizes 
the  functions  that  should  be  supported  by  simulator  control  consoles.  The 
number  of  people  in  each  category  cannot  be  specified  at  present,  but  would 
depend  on  research  requirements  and  resource  limitations. 
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Exercise  Designers 

Simulation  exercises,  whether  for  research  or  for  training,  may  be 
divided  conceptually  into  four  phases:  exercise  design,  compilation, 
execution,  and  analysis.  Exercise  designers  focus  primarily  on  the 
first  two  phases.  Exercise  design  involves  defining  research  variables 
or  training  objectives,  specifying  the  exercise  scenario  and  procedures, 
and  developing  or  selecting  performance  measures.  The  compilation 
phase  includes  defining  and  entering  modifications  to  the  simulation  data 
base  and  algorithm  base,  preparing  graphics,  and  modifying  performance 
measurement  routines.  A  large  portion  of  this  work  would  probably 
involve  the  manipulation  of  alphanumeric  information  in  tabular  form. 
Following  exercises,  the  designers  would  receive  feedback  in  the  form 
of  reports  prepared  by  the  research  staff. 

Exercise  Controllers 


The  two  major  categories  of  exercise  controllers  are  computer  operators 
and  researchers.  Computer  operators  would  be  responsible  for  the 
details  of  loading,  compiling,  and  executing  simulation  exercises,  and 
they  would  monitor  the  system  for  problems  during  an  exercise. 

A  researcher's  primary  responsibility  during  a  session  will  be  to 
monitor  operator/team  performance.  Rather  than  requiring  the  researcher 
to  look  over  the  shoulders  of  the  operator,  the  researcher  should  have  the 
capability  of  repeating  operator  imagery  on  his  or  her  own  console  display. 
This  visual  information,  coupled  with  voice  information  over  an  intercom, 
would  enable  the  researcher  to  monitor  performance  during  a  session.  In 
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addition,  graphic  displays  should  be  developed  especially  for  the  purpose 
of  summarizing  operator  performance.  In  a  1  v  1  intercept  simulation, 
for  example,  the  researcher  should  be  able  to  call  for  a  trace  of  the 
target  and  interceptor  flight  paths,  along  with  a  tabular  summary  of  the 
amount  of  time  and  fuel  consumed  and  any  unsafe  conditions  that  occurred. 

It  should  also  be  possible  to  direct  this  type  of  display  to  the  operator's 
console  for  feedback.  A  complete  definition  of  required  graphics  aids  for 
performance  assessment  and  feedback  will  depend  on  specific  research 
and  training  requirements. 

In  addition  to  monitoring  operator  performance,  researchers  should  be 
able  to  perform  umpire  functions  such  as  controlling  the  rate  of  simulation 
events. 

Following  a  session  the  researchers  will  need  a  detailed  listing  of 
performance  data  and  statistical  analyses  of  aggregated  data.  Performance 
data  should  be  available  in  both  tabular  and  graphics  form.  Computer 
technology  makes  possible  the  generation  of  vast  quantities  of  data- -the 
researcher /instructor  will  be  responsible  for  defining  performance  data 
needs  judiciously. 

Script  Readers  and  Role  Players 

Script  readers  and  role  players  play  the  part  of  personnel  who  are  external 
2 

to  the  AFC  team  being  tested.  Examples  of  typical  roles  are: 

•  Interceptor  pilots  and  other  air  crews 
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•  Blue  (own  force)  subordinate  or  superior  command 
staff  members 

•  Red  (enemy  force)  command  staff 

In  the  case  of  the  first  two  roles,  script  readers  and  role  players  would 

o 

provide  the  voice  input  to  the  AFC-  team  as  determined  by  exercise 
events  and  research  purposes.  In  the  third  role,  role  players  would  not 
interact  verbally  with  the  AFC"  team,  but  would  control  simulation  events 
as  necessary  to  achieve  research  objectives. 

A  script  reader's  primary  responsibilities  during  an  exercise  are  to 

watch  a  clock  and  read  items  from  a  prepared  script  at  specified  times. 

2 

Some  interaction  with  AFC  team  members  may  be  required.  For  example, 
a  script  reader  may  call  the  team,  wait  for  acknowledgment,  and  then 
continue  with  the  script.  Script  readers  currently  read  prepared  text 
from  formally  prepared  notebooks. 

Scripts  could  also  be  presented  on  the  console  display,  and  the  reader 
would  read  them  as  they  appeared.  This  approach  would  have  the 
advantages  of  ensuring  synchrony  between  the  script  and  simulated 
events  and  facilitating  the  maintenance  and  updating  of  scripts. 

In  some  cases  script  reader  functions  could  be  automated.  This  would 
be  possible  if  advanced  voice  synthesis  capabilities  were  included  in  the 
simulation.  Script  items  would  then  be  triggered  automatically  by  the 
clock  or  by  simulation  events. 
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A  role  player's  functions  are  to  monitor  exercise  events,  provide  verbal 
2 

inputs  to  the  AFC“  team  when  appropriate,  and  interact  with  team 
members  as  necessary.  A  simple  form  of  role  playing  in  current 
simulations  is  illustrated  by  T-4  drivers,  who  control  simulated  aircraft 
on  the  basis  of  instructions  from  students  and  instructors.  T-4  drivers 
must  also  respond  by  voice  in  the  same  way  pilots  would. 

More  sophisticated  role  playing  would  be  required  in  some  research 
applications.  Role  players  could  depict  the  command  headquarters  in 

9 

charge  of  the  experimental  AFC“  team,  for  example.  In  this  case, 

2 

intercom  connections  between  the  role  players  and  the  AFC  team  would 

simulate  radio-telephone  links.  Another  major  role  would  be  the  enemy 

command  center.  In  this  case,  role  players  would  function  as  adversaries 
2 

against  the  C  team.  Voice  links  between  the  two  teams  would  not  be 
appropriate  in  this  situation.  Instead,  the  Red  (enemy)  team  would 
initiate  certain  tactical  movements,  which  the  Blue  (own)  team  would 
detect  on  their  display  screens  and  counter  with  available  simulated 
resources. 

Script  readers  and  role  players  could  be  in-house,  contractor,  or  military 
personnel. 

2 

AFC  Team  Members 

2 

The  AFC  team  members  would  be  the  experimental  subjects  for  the 
2  2 

empirical  AFC  T  research  program.  They  would  typically  be  military 

2 

personnel  familiar  with  AFC  operations.  The  necessary  rank  and  level 
of  experience  of  the  team  members  would  vary  depending  on  research 
requirements  and  resource  constraints. 
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Software  Developers 


Software  developers  would  be  responsible  for  designing,  coding,  testing, 
and  debugging  the  software  modules  comprising  the  simulation  system. 
They  would  coordinate  with  exercise  designers  to  provide  the  required 
capabilities  for  each  exercise,  and  with  the  researchers  to  develop  the 
appropriate  interface  features  and  performance  assessment  routines. 
In-house  and  contractor  personnel  would  serve  as  software  developers. 

Maintenance  Personnel 


Maintenance  personnel  would  be  responsible  for  the  integrity  of  the 
hardware  and  software  systems.  Software  maintenance  functions  could 
be  performed  by  software  developers,  and  hardware  maintenance  could 
be  performed  by  vendor  personnel  or,  if  preferred,  by  in-house  technicians. 

SOFTWARE 

Figure  6  illustrates  the  major  software  modules  that  are  needed  for  the 
recommended  research  facility.  The  following  paragraphs  discuss  the 
functional  capabilities  required  for  each  module.  The  discussion  is  at  a 
high  level,  and  is  intended  to  outline  the  issues  to  be  considered  in 
subsequent  detailed  analyses. 
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Operating  System 

The  details  of  the  operating  system  are  relatively  unimportant  at  the 
present  high  level  of  discussion  except  that  the  system  should  facilitate 
the  jobs  of  the  computer  operators  and  the  software  development  and 
maintenance  personnel.  Features  that  would  be  desirable  are  a  powerful 
command  language,  access  to  high-level  languages  that  are  particularly 
well-suited  to  real-time  processing  and  graphic  displays,  a  convenient 
editing  system,  and  sophisticated  file  handling  and  data  base  management 
capabilities . 

Personnel  Support  Modules 

Personnel  support  modules  would  control  the  displays  and  interpret  the 

commands  of  all  users  of  the  system.  Much  attention  has  historically 

been  given  to  the  design  of  displays  and  control  functions  for  operators -- 
2 

AFC  team  members,  for  example- -but  very  little  effort  has  been 
directed  toward  defining  operator-system  interface  features  for  exercise 
controllers  and  other  system  users.  We  recommend  that  the  interfaces 
for  all  users  be  carefully  engineered  to  maximize  the  utility  of  the  system. 

Software  support  for  exercise  controllers,  particularly  researchers,  would 
be  especially  important  because  these  people  would  be  unlikely  to  be 
computer  professionals,  and  they  would  be  required  to  perform  accurately 
within  the  time  constraints  of  the  exercise.  Software  support  functions 
that  would  be  most  desirable  are  the  following: 
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•  Convenient  display,  entry,  and  modification  of  the  contents 
of  the  simulation  data  base.  Tabular  displays  of  the  data 
should  be  formatted  to  facilitate  reading.  Data  entry  and 
modification  procedures  should  be  designed  to  prevent 
errors  and  preclude  the  inadvertent  loss  of  data. 

•  Graphics  entry  and  modification  procedures  should  be  as 
streamlined  as  possible. 

•  An  interactive  dialog  system  should  be  developed  to  aid  the 
exercise  controller.  A  combined  menu  selection  and 
function  key  system  with  extensive  prompting  of  the  user 
is  recommended. 

•  Exercise  controllers  should  be  able  to  display  on  their 

own  consoles  a  copy  of  the  imagery  on  the  console  of  any 
2 

AFC  team  member  in  order  to  monitor  the  activity  of 
individuals. 

•  Performance  assessment  routines  should  be  developed 
to  permit  on-line  monitoring  of  team  and  individual 
performance  during  exercises.  Exercise  controllers 
should  be  able  to  specify  key  conditions  and  be  notified 
automatically  when  the  conditions  occur. 

•  Designing  and  running  data  analysis  routines  should  be 
convenient,  and  the  output  of  such  analyses  should  be 
formatted  to  facilitate  interpretation.  Graphic  output 
of  performance  analyses  should  be  possible. 
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This  is  a  partial  list  of  functions  that  should  be  performed  by  personnel 
support  modules.  The  list  should  be  expanded  on  the  basis  of  a  detailed 
analysis  of  the  functions  of  exercise  controllers.  Comparable  analyses 
should  be  performed  for  the  other  personnel  categories  listed  in  Figure  5. 

Simulation  Models 


Simulation  models  should  be  developed  for  the  following  elements  of  the 
2 

C  environment: 

2 

•  C  communication  network 

•  Superteam  and  sub  team  elements 

•  Own  aircrews 

•  Aerial  combat  tactics 

\ 

•  Air  weapons 

•  Sensor  systems 

•  Communications  and  radar  countermeasures 

•  Tactical  situation 

The  functions  of  these  models  are  described  below. 

2 

C  Communication  Network  Models  —  The  system  should  be  capable  of 

2 

simulating  a  variety  of  C  voice  communications  networks.  A  fundamental 
network  could  include  a  single  weapons  director  and  an  individual  pilot, 
for  example.  An  expanded  network  would  include  an  entire  weapons  team 
and  controlled  aircrews.  The  communication  network  data  base  should 
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allow  the  researcher  to  specify  the  number  of  nodes  in  the  network  and 

2 

the  routes  between  nodes.  In  addition  to  the  actual  members  of  the  AFC“ 
team,  the  communication  networks  should  include  exercise  control 
personnel,  script  readers,  and  role  players. 

The  network  models  should  interact  with  the  communication  control  panel 
so  that  communication  can  be  controlled  by  the  panel.  The  amount  of 
control  allocated  to  the  operator  would  be  determined  by  the  researcher. 
The  models  should  be  capable  of  replicating  the  volume  of  voice  traffic 
that  can  realistically  be  anticipated  on  each  voice  channel. 

Superteam  and  Subteam  Element  Models--These  models  are  closely  related 

"  ~  2 

to  the  communication  network  models  in  that  the  relevant  set  of  AFC  team 

participants  should  be  specified  for  each  exercise,  and  communication 
among  all  team  members  should  be  feasible.  It  should  be  possible  to 
define  the  experimental  (or  training)  team  on  any  of  several  levels,  and 
it  should  then  be  possible  to  model  the  necessary  subteam  and  superteam 
elements.  Two  examples  illustrate  this  point. 

If  the  experimental  team  had  an  AWACS-like  structure,  it  would  include 
weapons,  surveillance,  battle  staff,  and  system  support  subteams.  The 
team  would  exist  in  a  larger  command  structure  that  would  include  a 
TACC,  perhaps,  and  several  aircrews.  The  TACC  staff  and  aircrews 
would  comprise  the  supterteam,  of  which  the  experimental  team  is  a 
part. 
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As  a  second  example,  the  experimental  team  of  interest  could  consist 
only  of  a  weapons  section.  The  superteam  at  this  level  would  consist  of 
the  other  collateral  sections,  as  well  as  aircrews  and  superordinate 
command  groups. 

Regardless  of  the  level  of  analysis,  the  superteam  members  should 
generate  inputs  to,  and  respond  to  outputs  from,  the  experimental  team. 
The  inputs  and  responses  can  arise  from  two  sources:  personnel  and 
software.  Script  readers  would  provide  voice  inputs  in  situations  that 
are  relatively  constrained.  Role  players  would  generate  voice  inputs  in 
situations  that  are  less  constrained,  and  they  would  also  manipulate 
simulation  events  in  response  to  the  actions  of  the  experimental  team. 

It  may  be  possible  to  develop  software  to  automate  the  functions  of  some 
script  readers  and  role  players  if  state-of-the-art  automatic  voice 
recognition  and  synthesis  capabilities  are  exploited.  The  superteam 
members  that  can  be  automated  most  feasibly  are  the  aircrews  because 
their  legal  vocabulary  and  range  of  response  are  extremely  constrained. 
Because  it  is  unlikely  that  the  processing  performed  by  a  superordinate 
command  staff  could  be  adequately  modeled  soon,  such  functions  would 
probably  need  to  be  performed  by  skilled  role  players. 

Own- Aircrew  Mod  els --The  possibility  of  automating  own-aircrew  functions 
in  the  simulator  requires  further  elaboration.  Two  separate  problems 
need  to  be  solved  before  this  approach  will  be  feasible:  interface 
processing  and  performance  modeling.  Interface  processing  involves 
the  ability  of  the  system  to  recognize  voice  inputs  from  experimental 
team  members.  The  recognition  error  rate  for  the  system  should  match 
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the  typical  rate  for  human  role  players.  If  this  hurdle  can  be  passed, 
other  interface  problems  are  also  likely  to  be  resolvable  and  certain 
advantages  can  be  realized. 

One  advantage  is  that  fewer  people  would  be  required  for  controlling 

exercise.  In  addition,  if  initial  recognition  performance  is  good,  it 

should  be  possible  to  degrade  recognition  performance  systematically. 

This  would  permit  the  empirical  evaluation  of  the  effects  of  communications 
2 

jamming  on  AFC“  team  and  system  performance,  for  example. 

Adequate  aircrew  performance  modeling  would  enable  researchers  to 

define  and  manipulate  various  parameters  of  aircrew  performance.  One 

such  parameter  could  be  the  lag  between  receiving  a  direction  and  actually 

initiating  a  maneuver.  Another  could  be  the  characteristics  of  the 

maneuver:  one  simulated  pilot  could  pull  lg  when  turning  to  a  new 

heading,  whereas  another  would  pull  2g.  This  variance  could  be 

2 

manipulated  systematically  to  expose  the  C  team  to  a  range  of 
conditions. 

The  output  side  of  the  aircrew  model  also  offers  advantages  over  human 
role  players.  Skilled  T-4  drivers  can  develop  two  or  three  voices,  so 
that  each  pilot  will  sound  different  to  the  controller.  Most  T-4  drivers, 
however,  use  the  same  voice  for  all  roles.  Automatic  voice  synthesis 
routines  could  be  developed  to  generate  a  unique  sound  for  each  simulated 
pilot.  The  emotional  inflections  and  nonstandard  or  nonsensical  utterances 
of  pilots  under  stress  may  be  difficult  to  simulate,  but  this  problem  is 
not  unique  to  automatic  voice  synthesis:  Human  role  players  also  have 
difficulty  simulating  such  dialog. 
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Aerial  Combat  Tactics  Models --In  a  standard  intercept  situation  the 
weapons  director  guides  the  interceptor  pilot  toward  the  target  until 
the  pilot  can  acquire  it  directly,  either  visually  or  electronically.  This 
basic  situation  can  be  elaborated  on  by  increasing  the  number  of  intercept 
and  target  aircraft  involved,  and  by  simulating  realistic  aerial  combat 
maneuvers.  Knowledge  of  both  friendly  and  enemy  aerial  combat  tactics 
can  be  embodied  either  in  role  players  or  in  simulation  software.  Both 
Red  and  Blue  tactics  should  be  included.  The  target  should  perform 
realistic  evasive  maneuvers. 

Role  players  can  handle  relatively  simple  situations,  but  many-vs-many 

encounters,  such  as  would  be  encountered  in  high-intensity  scenarios, 

probably  require  automated  assistance.  Software-controlled  simulated 

aerial  engagements  would  generate  a  realistic  "fur  ball"  on  the  display, 

2 

and  would  enable  the  evaluation  of  the  ability  of  the  C  team  to  identify 
and  recover  friendly  aircraft  following  mass  air  battles.  Even  in 
low-intensity  situations,  automated  tactics  would  reduce  the  workload 
of  simulator  control  personnel  by  controlling  all  combat  maneuvers  for 
intercepters  and  targets  following  a  "Judy.  " 

In  addition  to  air-to-air  combat  models,  air-to-ground  missions  should 
also  be  modeled  so  that  close-air  support  (CAS)  and  strike  control  and 
armed  reconnaissance  (SCAR)  missions  may  be  exercised.  In  this  way 
teams  such  as  the  Tactical  Air  Control  Party  (TACP)  and  Forward  Air 
Control  Post  (FACP)  could  be  observed  or  trained.  The  algorithms  for 
air-to-ground  combat  would  be  similar  to  air-to-air  models  except  that 
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the  velocities  of  the  targets  would  be  lower  than  airborne  targets  (zero  in 
the  case  of  fixed  installations)  and  altitude  above  ground  level  would  be 
zero. 

Air  Weapons  Model- -The  simulator  should  include  current  models  of 
airborne  weapons  platforms,  munitions  capabilities,  and  ground-based 
air  defense  weapons.  Platform  models  should  include  parameters  for 
velocity,  acceleration,  turn  rate,  climb  rate,  fuel  capacity,  fuel 
consumption  rate,  and  any  other  flight  dynamics  characteristics  that 
are  judged  to  be  relevant.  Airborne  sensor  system  capabilities  (visual 
or  electronic)  should  also  be  modeled.  These  capabilities  would  be 
represented  by  parameters  for  probability  of  detection  as  a  function  of 
range,  heading,  target  size,  and  environmental  conditions.  All  aircraft 
could  be  characterized  by  the  same  set  of  parameters,  and  the  researcher 
would  define  the  particular  mix  and  capabilities  of  aircraft  appearing 
during  the  exercise  by  entering  the  appropriate  parameter  values  into 
the  simulation  data  base.  If  an  exercise  involved  intercept  runs  against 
high-performance  aircraft,  high  maneuver  rates  would  be  entered;  if 
bomber  intercepts  were  being  practiced,  the  data  base  would  contain  high 
maneuver  rates  for  the  interceptors  and  low  rates  for  the  bombers. 

Airborne  munitions  capabilities  need  to  be  simulated  for  the  purpose  of 
scoring  kills  during  a  simulated  engagement.  Details  about  the  velocity, 
range,  and  lethal  areas  of  munitions  would  not  necessarily  need  to  be 
included  in  the  simulation,  but  this  information  should  feed  into  analyses 
of  kill  probabilities  as  a  function  of  heading,  range,  relative  velocity, 
and  the  ECM/ECCM  environment,  and  the  probability  functions  should  be 
included  in  the  software.  Targets  that  are  destroyed  should  be  automatically 
removed  from  the  displays. 
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Sensor  System  Models --The  simulator  should  include  versatile  models  of 
primary  sensor  systems.  The  simulator  would  of  course  "know"  the  true 
position  of  all  aircraft  in  the  scenario,  and  exercise  controllers  should  be 
able  to  view  such  ground  and  air  truth  information  when  required.  Radar 
models,  however,  should  degrade  detection,  discrimination,  and  location 
performance  as  a  function  of  range,  radar  parameters,  target  reflectance, 
and  ECM/ECCM  conditions.  The  values  for  all  parameters  should  form  a 
part  of  the  simulation  data  base. 

Sensor  models  should  respond  in  realistic  ways  to  ECM  disruption  and 
other  environmental  factors .  Further,  radar  input  countermeasures 
operators  (RICMO)  should  be  able  to  adjust  radar  parameters  (frequency, 
mode,  etc)  to  counteract  the  interference.  The  imagery  should  change  as 
a  function  of  RICMO  inputs.  This  type  of  versatility  is  not  currently 
implemented  in  AWACS  or  CRC/CRP  training  systems  although  the  need 
for  it  is  recognized  by  the  users. 

Communications  and  Radar  Countermeasures  Models  -  -  Comm  uni  cations 

and  radar  countermeasures  effects  should  be  modeled.  The  simulator 

should  be  able  to  replicate  various  levels  and  types  of  voice  communication 

jamming.  When  simulated  aircraft  are  jammed,  the  pilot's  response 

(either  simulated  or  depicted  by  role  players)  should  indicate  communica- 

2 

tion  difficulties.  When  the  AFC  team  is  jammed,  the  headphones  should 
carry  acoustic  noise  in  addition  to  the  actual  message.  The  characteristics 
of  the  noise  should  match  the  characteristics  of  typical  communications 
jamming  devices.  Radar  countermeasures  models  should  generate  display 
characteristics  that  accurately  depict  the  effects  of  chaff  distribution, 
jamming,  and  other  ECM  techniques. 
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Countermeasures  models  should  be  interactive  in  the  sense  that  exercise 
controllers  can  invoke  them  as  needed  during  an  exercise.  This  capabil¬ 
ity  would  be  required  in  order  to  evaluate  team,  particularly  RICMO 
subteam,  response  to  interference.  It  should  also  be  possible  to  call 
countermeasures  models  automatically,  according  to  a  predetermined 
schedule  or  in  response  to  predefined  events. 

Tactical  Situation  Models --The  software  models  in  this  category  comprise 
what  may  be  termed  the  "driver  scenario"  for  simulation  exercises.  The 
researcher  would  create  scenarios  for  specific  purposes  by  defining  the 
set  of  Red  and  Blue  resources  to  be  included,  their  geographical 
distribution  and  objectives,  and  relevant  environmental  conditions.  Blue 
and  Red  force  resources  data  would  include  such  things  as  the  number  of 
aircraft,  armaments  for  each  class  of  aircraft,  and  ground-based  air 
defense  weapons.  The  data  bases  for  the  aircrew,  aerial  combat  tactics, 
and  air  weapons  models  would  need  to  be  entered  or  modified  to  meet  the 
research  or  training  requirements  of  the  exercise. 

The  simulator  should  include  models  for  air  defense  weapons  for  both 
Blue  and  Red  forces.  Each  air  defense  site  should  be  defined  in  terms 
of  the  firing  rate,  ammunition  supply,  and  kill  probabilities  as  a  function 
of  target  range,  altitude,  and  performance  characteristics. 

The  researcher  should  be  able  to  define  the  geographical  distribution  of 
Red  and  Blue  forces.  The  geographical  array  should  be  completely 
flexible  so  that  fictional  areas  can  be  simulated  for  some  applications; 
whereas  specific  regions  of  the  world  can  be  simulated  for  other 
applications. 
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It  should  be  possible  to  define  the  objectives  of  the  Blue  and  Red  forces. 

Objectives  would  typically  be  defined  in  terms  of  paths  to  targets  from 

the  initial  staging  areas,  and  return  paths  from  the  target  to  recovery 

fields.  Red  forces  in  most  cases  would  be  programmed  to  attack  or 

defend  certain  areas,  and  interactive  control  of  Red  movements  would 

be  necessary  only  in  selected  exercises.  Blue  forces,  on  the  other  hand, 

2 

would  be  under  the  control  of  the  C  team.  Blue  movements  would  proceed 
according  to  the  commands  of  the  team  members,  who  would  be  attempting 
to  meet  the  objectives  of  the  exercise.  In  some  cases  it  would  probably 
be  necessary  for  the  Red  forces  to  be  under  the  control  of  simulation 
control  personnel,  who  would  be  playing  the  role  of  the  Red  battle  staff. 

In  these  cases  it  should  be  possible  to  hold  two-sided,  free-play  war 
gaming  exercises. 

The  tactical  situation  models  should  allow  the  researcher  to  specify 
certain  relevant  environmental  conditions:  weather,  day /night  operations, 
ECM/ECCM  environment,  and  so  forth.  Selection  of  a  set  of  environmental 
parameters  should  determine  which  subsets  of  the  data  bases  for  many  of 
the  other  software  models  would  be  relevant,  and  it  should  cause  appropri¬ 
ate  correction  factors  to  be  used  as  necessary.  For  example,  the  visual 
target  detection  range  should  be  different  for  night  operations  than  for  day 
operations. 

Tactical  situation  models  would  be  the  driver  scenario  in  the  sense  that 

they  would  drive  the  movements  and  behavior  of  Red  and  Blue  forces 

according  to  a  plan.  The  plan  would  be  predetermined  by  the  researcher/ 

2 

instructor,  but  it  should  unfold  according  to  the  actions  of  the  AFC  team. 
Mistakes  by  the  team  should  be  followed  by  realistic  Red  gains  and  Blue 
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losses;  excellent  C“  team  performance  should  be  followed  by  events  that 
are  more  advantageous  to  the  Blue  forces.  Whatever  the  outcome,  the 
driver  scenario  Should  be  tied  to  the  display  control  software  module  so 
that  imagery  realistically  depicting  the  simulated  events  would  appear 
on  the  operator  displays. 

Simulation  Data  Base  and  Algorithm  Base 

Each  of  the  models  described  above  should  be  developed  in  the  form  of 
generalized  parameters  that  can  be  set  in  any  of  a  range  of  values.  The 
specific  values  for  a  particular  application  should  be  stored  in  a  data  base 
that  could  be  readily  accessed  by  exercise  design  and  control  personnel. 

In  addition  to  the  data  base,  the  models  should  also  access  a  modular 
algorithm  base  that  includes  the  subroutines  required  for  performing 
specialized  functions.  It  should  be  possible  for  software  developers  to 
refine  the  algorithm  base  by  modifying  or  replacing  selected  algorithms 
as  necessary  to  meet  research  requirements. 

Applications  Programs 

Software  development  personnel  should  have  the  capability  to  prepare  and 
use  special-purpose  applications  programs  as  the  need  arises. 
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CHAPTER  III 


POTENTIAL  IMPACT  OF  ADVANCED  SIMULATION 
TECHNOLOGY  ON  AFC2T2  PROGRAMS 


The  state  of  the  art  in  simulation  technology  provides  the  capability  for 

2  2 

dramatically  improving  the  cost-effectiveness  of  AFC  T  programs. 

The  improvements  can  be  achieved  through: 

•  Presenting  a  wider  range  of  training  problems 

•  Achieving  greater  tactical  realism 

•  Increasing  the  amount  and  quality  of  student  practice  time 

•  Improving  the  efficiency  of  live  exercises 

•  Making  improved  use  of  instructor  time  and  talents 

•  Setting  higher  standards  of  proficiency 

The  following  sections  outline  these  benefits  in  more  detail. 

WIDER  RANGE  OF  TRAINING  PROBLEMS 
2 

AFC  teams  must  deal  quickly  and  effectively  with  a  variety  of  complex 

tactical  problems.  A  flexible  simulation  system  would  enable  instructors 
2 

to  expose  C  teams  to  a  wider  range  of  conditions  than  is  possible  with 

2 

current  simulators.  The  payoff  for  this  flexibility  would  be  C  teams 
which  are  prepared  to  react  and  adapt  to  unanticipated  contingencies  in 
the  operational  environment. 
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Current  C“  simulators  do  not  have  the  flexibility  that  is  required  to 

generate  a  broad  range  of  combat  conditions.  T-2  exercises  on  the 

TSQ-91  (CRC),  for  example,  require  complex  development  procedures 

that  are  not  generally  available  to  instructional  personnel.  The  T-4 

system  adds  capabilities  that  alleviate  some  of  the  problems  with  the  T-2, 

but  it  is  severely  limited  in  terms  of  the  number  and  types  of  aircraft 

tracks  that  it  can  generate.  Furthermore,  details  of  the  architecture 

make  even  minor  modifications  in  its  performance  characteristics 

prohibitively  difficult.  Numerous  exercises  combining  T-2  and  T-4 

capabilities  have  been  developed  but  they  are  extremely  difficult  to 

modify.  As  a  result,  the  exercises  present  only  a  relatively  small 

2 

sample  of  the  tactical  problems  to  be  faced  by  operational  C  teams, 
they  tend  to  be  outdated,  and  they  lack  the  flexibility  to  be  revised  by 
instructional  personnel. 

The  AWACS  simulator  is  newer  and  considerably  more  capable  than  the 

T-2  and  T-4  devices.  Moreover,  it  is  supported  by  System  Exercise 

Problem  Packages  (SEPPs).  SEPPs  are  computer-driven  tactical 

2 

exercises  intended  to  provide  experience  for  C  teams  in  performing 
tactical  operations  at  graded  levels  of  intensity  in  a  variety  of  geographical 
areas.  The  SEPPs  are  potentially  much  more  valuable  than  T-2  or  T-4 
exercises  in  exercising  a  broad  range  of  training  problems,  but  they  are 
difficult  to  use  and  cannot  be  readily  updated  by  instructional  personnel 
who  are  not  software  professionals.  SEPPs  consequently  tend  to  be 
underused  and  do  not  actually  provide  the  broad  range  of  problems  that 
they  were  intended  to. 
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GREATER  TACTICAL  REALISM 


AFC  teams  will  be  more  likely  to  be  able  to  perform  effectively  in  actual 

operational  settings  if  simulation  exercises  present  realistic  combat 

2 

contingencies.  The  AFC“  systems  we  surveyed  do  not  represent  mid-  or 
high-intensity  engagements  based  on  realistic  numbers,  densities, 
distribution,  capabilities,  and  tactics  of  own  and  threat  forces.  Moreover, 
it  is  difficult  to  modify  the  models  and  data  base  to  permit  the  simulation 
of  various  levels  of  intensity,  force  ratios,  and  weapons  mixes.  Simulation 
capabilities  such  sis  those  outlined  in  Chapter  II  are  required  for  this  type 
of  realism  and  flexibility. 

INCREASED  AMOUNT  AND  QUALITY  OF  STUDENT  PRACTICE  TIME 

Advanced  simulation  technology  can  potentially  provide  additional 
capabilities  for  students  to  practice  control  and  surveillance  techniques 
privately,  without  requiring  instructor  or  staff  participation.  A  student 
weapons  controller,  for  example,  could  log  on  to  a  simulation  console, 
select  an  exercise  or  ask  the  system  to  select  one  appropriate  to  his  skill 
level,  and  run  it.  Such  exercises  would  require  the  display,  scenario, 
and  automatic  voice  recognition /synthes is  capabilities  described  in 
Chapter  II. 

The  approach  outlined  above  is  a  form  of  computer-based  training  (CBT). 

It  shares  with  other  computer-based  techniques  the  advantages  of  enhancing 
student  motivation  by  allowing  private,  self-paced  instruction  that  can  be 
adapted  to  the  student's  performance  level,  given  performance  measure¬ 
ment  techniques  and  optimization  routines.  Moreover,  in  contrast  to 
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traditional  read-and-respond  approaches  to  computer-assisted  instruction 
(CAI)  that  require  verbal/typed  responses,  the  recommended  approach 
emphasizes  dynamic  free-play  and  task-oriented  responses. 

The  individualized  CBT  exercises  would  not  necessarily  replace  or  even 
reduce  the  amount  of  time  students  spend  in  contact  with  instructors  or  in 
team  exercises.  Instead,  the  purpose  is  to  increase  the  quality  of 
instructor  interaction  and  team  exercises.  This  would  occur  because  the 
instructor  would  be  freer  to  deal  with  substantive  issues  raised  by  students 
on  the  basis  of  the  simulation  experience.  Team  exercises  could  also 
potentially  be  enhanced  because  team  members  individually  could  enter 
the  exercises  at  a  higher  level  of  proficiency  than  is  currently  possible 

The  CBT  approach  could  operate  in  the  manner  of  a  CAI  study  carrel 

system  in  a  learning  center.  It  would  be  most  appropriate  for  initial 

training  and  initial  transition  training  of  individual  skills  for  all  personnel 

categories  shown  in  Figure  1.  It  could  also  be  used  for  advanced  training 

and  perhaps  for  subteam  training,  although  such  applications  would  be 

more  difficult.  Individualized  instruction  in  learning  centers  is 

well  accepted  and  effectively  used  at  many  of  the  sites  we  visited-- 

provided  that  instructors  and  students  perceive  that  the  instructional 

material  is  valid  and  useful.  The  CBT  approach  would  therefore  be 

2 

consistent  with  current  AFC  training  practice. 

IMPROVED  EFFICIENCY  OF  LIVE  EXERCISES 

Live  exercises  are  too  costly  to  use  in  providing  training  that  can  be 
delivered  as  effectively  or  more  effectively  in  simulation  exercises. 
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Consider  the  example  of  a  student  weapons  director  who  is  learning  to 
control  live  intercepts.  A  partial  list  of  participants  includes: 

•  The  student 

•  Another  student  who  is  playing  the  role  of  weapons  technician 

•  An  instructor  who  is  overseeing  the  entire  exercise 

•  Aircrews  for  the  interceptor  and  target  aircraft 

•  Air  traffic  control  and  aircraft  maintenance  personnel 

Such  exercises  entail  a  very  real  risk  of  injury  and  property  damage,  and 

require  hours  of  planning,  attending  pre-  and  post-mission  briefings, 

and  the  consumption  of  jet  fuel  and  flight  resources.  The  payoff  may  be 

only  a  few  minutes  of  time  on  the  scope  actually  controlling  aircraft, 

time  which  may  be  cut  short  because  of  weather  or  mechanical  problems. 

AWACS  exercises  are  considerably  more  expensive  because  the  students 

are  themselves  airborne,  which  requires  a  complete  flight  crew,  jet 

fuel,  and  ground  air  traffic  control,  logistics,  and  maintenance  support. 

2 

Large-scale  multisite  C  exercises  are  tremendously  more  expensive 
than  the  examples  cited  above  because  large  numbers  of  aircraft,  ground 
facilities,  and  personnel  are  required. 

Given  the  cost  of  such  exercises,  it  is  unfortunate  that  participants  use  a 
major  portion  of  the  exercise  time  learning  basic  functions  that  could  be 
exercised  if  simulation  capabilities  such  as  those  described  in  Chapter  II 
were  available.  In  this  case  a  larger  proportion  of  live  exercise  time 
could  be  spent  developing  the  team  and  superteam  coordination  skills  that 
cannot  feasibly  be  developed  in  simulation  exercises. 
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IMPROVED  USE  OF  INSTRUCTOR  TIME  AND  TALENTS 

It  is  possible  within  the  current  state  of  the  art  to  free  instructors  from 
the  more  routine  duties  of  monitoring  and  evaluating  student  performance. 
Instructors  could  then  devote  time  to  other  activities  such  as  planning, 
tutoring,  and  diagnosis,  which  are  more  appropriate  channels  for  their 
skills  and  knowledge.  Volume  I,  Chapter  II,  identifies  instructional 
support  features  that  should  be  incorporated  into  the  design  of  training 
simulators. 

For  convenience,  the  list  is  repeated  below: 

•  Automated  assessment  and  monitoring  of  operator  and 
team  performance 

•  Presentation  of  performance  data  to  instructors 

•  Automated  branching  among  lesson  segments  on  the 
basis  of  student  or  team  performance 

•  Automated  delivery  of  feedback  and  prompting  to  students 
and  teams 

•  Capability  for  simulating  events  in  real  time  and  at  rates 
other  than  real  time 

•  Capability  for  replaying  simulated  events 

•  Part-task  training  capabilities --the  ability  to  exercise 
a  subset  of  the  operator's  or  team's  duties 

•  Capability  for  presenting  successive  approximations  to 
the  quality  and  appearance  of  imagery  on  a  display  scope 
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•  Flexibility,  ease  of  maintenance,  and  convenient 

modifiability  so  that  instructors  who  are  not  computer 
professionals  can  make  necessary  changes  in  the  data  base 
and  models  driving  exercise  scenarios 

The  design  outlined  in  Chapter  II  of  the  present  volume  provides  for  the 
definition  and  development  of  these  features.  The  first  four  features 
depend  on  the  development  of  operator  and  team  performance  measurement 
techniques,  which  is  a  major  research  issue  in  itself. 

These  features  would  increase  training  efficiency  by  reducing  the  amount 
of  instructor  time  required  for  each  hour  of  student  time.  The  ability  of 
the  training  device  to  monitor  and  evaluate  student  performance,  for 
example,  would  substantially  reduce  the  requirement  for  instructor  time. 
Current  practice  in  Basic,  APQ,  and  AWACS  training  is  for  an  instructor 
to  monitor  one  or  two  students  as  they  are  working  on  scopes.  Such 
attention  is  appropriate  in  live  exercises,  in  which  safety  is  a  paramount 
concern,  but  the  instructors  we  interviewed  felt  their  time  would  be  better 
spent  on  other  duties  during  most  simulation  training. 

The  automatic  monitoring  function  could  be  designed  to  detect  impending 
unsafe  conditions,  and  it  could  also  make  qualitative  assessments  of 
operator  and  team  performance.  Software-induced  alarms  could  then 
warn  the  instructor  whenever  operator  or  team  performance  falls  below 
criterion  or  is  about  to  become  unsafe.  This  would  free  the  instructor 
to  be  present  for  a  particular  student  or  team  only  when  his  presence  is 
most  important. 
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Another  instructional  support  feature  that  would  help  relieve  the  instructor 
from  some  of  his  present  duties  would  be  automated  recordkeeping  and 
lesson  control.  The  instructional  staff  could  then  set  criteria  for  each 
unit  of  instructional  material.  As  operators  or  teams  met  the  criteria, 
they  would  be  branched  to  the  next  unit.  Failure  to  meet  criteria  would 
flag  the  instructor  or  branch  the  operator  or  team  back  for  remediation. 

The  student  records  generated  in  this  process  could  be  made  available  to 
instructors  in  summary  form  or  in  as  much  detail  as  desired. 

The  ability  of  the  training  device  to  monitor  student  performance  and 
maintain  performance  records  would  permit  instructors  to  focus  their 
attention  on  instructional  planning  and  on  specialized  interaction  with 
students.  These  benefits  would  permit  a  greater  flow  through  the  training 
pipeline  without  a  corresponding  increase  in  the  required  number  of 
instructors.  This  consideration  is  most  important  in  academic,  school 
settings  in  which  large  numbers  of  students  are  involved.  Small 
on-the-job  training  (OJT)  programs  would  also  benefit  from  these 
capabilities  because  of  their  limited  instructor  resources.  In  either 
case,  initial  training  or  in-unit  OJT,  the  recommended  instructional 
support  features  would  enable  a  given  instructional  staff  to  deliver  more 
training  than  is  currently  possible. 

The  instructional  support  functions  discussed  above,  particularly  automatic 

performance  assessment,  are  technically  difficult.  One  major  function  of 

2  2 

the  recommended  AFC  T  research  facility  should  be  to  explore  their 
feasibility. 
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HIGHER  PROFICIENCY  STANDARDS 


Training  developers,  managers,  and  instructors  at  all  sites  we  visited 
expressed  a  common  concern:  the  skill  and  knowledge  level  of  entrants 
into  the  17xx  career  field  has  apparently  been  dropping  over  the  past 
several  years  and  is  continuing  to  drop.  The  required  number  of  17xx 
personnel  has  not  decreased,  however.  This  has  forced  schools  to 
reduce  performance  requirements  for  graduation.  Courses  that  may 
once  have  required  proficiency  in  4  v  2  intercepts  (four  interceptors 
vs  two  hostile  aircraft)  for  example,  may  only  require  2  v  1  proficiency 
now.  This  reduction  in  training  standards  has  a  ripple  effect  throughout 
the  training  pipeline.  As  one  means  of  reducing  or  reversing  this  decline, 
many  of  the  experts  we  interviewed  recommended  establishing  screening 
tests  and  other  measures  to  increase  the  entry  level  of  new  personnel. 

Another  approach  would  be  to  modify  the  training  programs  to  meet  the 
requirements  of  the  new  personnel.  This  would  be  a  major  undertaking 
requiring  substantial  personnel  resources,  time,  and  facilities,  but 
advanced  simulation  technology  offers  the  potential  for  aiding  in  this 
process. 

If  advanced  simulation  technology  achieves  the  potential  benefits  outlined 
in  the  present  chapter,  it  may  play  a  direct  role  in  increasing  the 
proportion  of  students  who  meet  or  exceed  course  criteria.  The  ability 
to  practice  on  a  wider  range  of  tactically  realistic  exercise  problems 
than  is  currently  possible  can  improve  the  performance  capabilities  of 
students  and  teams.  The  increased  motivation  and  confidence  derived 
from  these  exercises  in  conjunction  with  advanced  CAI  techniques  can 
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enhance  the  benefits  of  live  exercises.  Instructional  support  features  of 

advanced  simulators  can  potentially  improve  the  level  and  quality  of 

2 

instructor  interaction  with  C  students  and  teams.  All  of  these  factors 

working  together  can  potentially  allow  training  standards  to  be  raised 

from  present  levels  to  meet  the  actual  requirements  of  the  operational 

environment.  If  this  potential  is  realized,  advanced  training  simulation 

technology  will  have  made  a  substantial  contribution  to  the  readiness  of 
2 

tactical  AFC  systems  and  teams. 
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CHAPTER  IV 


TECHNICAL  FEASIBILITY  OF  THE  RECOMMENDED 
AFC2T2  RESEARCH  FACILITY 


The  present  chapter  provides  an  initial  assessment  of  the  technical 

2  2 

feasibility  of  the  major  features  of  the  recommended  AFC  T  research 
facility.  Because  the  system  is  a  many-faceted  device,  the  feasibility 
of  building  it  cannot  be  described  with  a  unitary  measure.  Many  of  its 
features  are  feasible  given  current  simulation  technology.  Others  will 
require  significant  advances  in  the  state  of  the  art.  Tbe  first  two  sections 
of  this  chapter  discuss  the  feasibility  and  risk  of  the  hardware  and  software 
features  of  the  design.  Feasibility  and  risk  are  assessed  in  a  relatively 
subjective  fashion  based  on  professional  judgment  and  experience.  In 
order  to  provide  a  more  substantive  basis  on  which  to  judge  the  feasibility 
of  the  recommendations,  the  third  section  describes  a  set  of  simulation 
systems  that,  taken  together,  combine  many  of  the  features  of  the 
recommended  research  facility,  although  no  single  system  currently 
embodies  the  entire  set  of  capabilities. 

FEASIBILITY  OF  HARDWARE  FEATURES 

The  hardware  comprising  the  recommended  research  facility  consists  of 
the  following  functional  units : 


•  Console  equipment 
--Displays 


--Keyboards  (function  and  alphanumeric) 

--Track  ball 
--Communication  gear 

•  Processing  equipment 

•  Automatic  voice  recognition  and  synthesis  equipment 

•  Large-screen  displays 

•  Other  peripheral  units 
--Printer 

— Digitizer  and  map  bug 
--Mass  storage  devices 

The  greatest  hardware  risk  lies  in  the  areas  of  voice  recognition  and 
synthesis.  Accurate  and  reliable  voice  recognition  devices  have  been 
developed  and  are  commercially  available  at  modest  cost.  The  systems 
are  currently  able  to  recognize  only  isolated  words,  but  most  are  unable 
to  parse  utterances  into  multiword  strings.  Careful  analysis  is  required 
in  order  to  determine  whether  this  limitation  is  critical.  It  is  possible 
that  brevity  codes  are  such  that  an  isolated  word  recognizer  could 
function  adequately  in  models  of  interceptor  pilots,  even  without 
sophisticated  parsing  capabilities.  Such  capabilities  would  be  mandatory 
if  command  staff  and  other  complex  superteam  elements  were  to  be 
automated. 

Much  less  risk  is  associated  with  automatic  voice  synthesis.  Implemen¬ 
tation  options  range  from  true  synthesis,  on  one  end  of  the  continuum,  to 
random  access  to  prerecorded  utterances  (on  tape  or  audio  disks)  on  the 
other.  The  simulation  needs  the  capability  to  generate  a  unique  voice  for 
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each  simulated  pilot  or  user  the  C“  team  interacts  with.  It  would  also  be 
valuable  to  develop  a  model  that  would  cause  the  intonation  and  inflection 
of  the  synthesized  voice  to  change  as  a  function  of  situational  variables 
that  normally  affect  aircrew  stress  and  workload,  although  such  modeling 
would  be  difficult  technically. 

Role  players  and  script  readers  serve  the  functions  of  voice  recognizers 
and  synthesizers  in  current  simulators.  Cost-benefit  analyses  are 
required  to  determine  the  actual  value  of  automating  these  functions. 

An  important  consideration  in  this  analysis  is  that  a  potentially  large 
number  of  role  players  will  be  required  if  scenarios  calling  for  realistic 
air  traffic  densities  are  developed.  In  addition,  reliability  and  repeata¬ 
bility,  which  are  important  considerations  for  a  research  device,  are 
likely  to  be  greater  for  an  automated  system.  For  these  reasons  we 
recommend  using  automatic  voice  recognition/synthesis  capabilities  in 
selected,  well  defined  domains. 

Except  for  voice  recognition /synthes is,  the  level  of  technical  risk 
associated  with  each  unit  is  low.  All  units  are  available  commercially 
and  may  be  procured  without  modification.  The  technical  difficulty  in 
building  the  simulator  lies  almost  exclusively  in  software  development. 

FEASIBILITY  OF  SOFTWARE  FEATURES 

Figure  6  illustrates  six  major  software  modules  that  are  required  for 

2  2 

the  recommended  AFC  T  research  facility: 


•  Operating  system 

•  Personnel  support  modules 

•  Simulation  models 

•  Simulation  data  base 

•  Algorithm  base 

•  Applications  programs 

Of  these,  the  only  modules  that  entail  substantial  technical  risk  are  the 

personnel  support  modules  (particularly  for  the  exercise  controllers  and 
2 

AFC  team  members)  and  the  simulation  models.  The  feasibility  of 
these  modules  is  addressed  in  the  following  pages.  In  addition,  two 
approaches  to  the  representation  of  teams  and  team  tasks  are  also 
discussed  because  of  the  central  importance  of  this  problem  to  the 
development  of  successful  software. 

2 

Software  to  Support  Functions  of  AFC  Team  Members 

2 

The  personnel  support  modules  for  AFC  team  members  should  be  able 
to  perform  the  following  functions : 

•  Display  visual  imagery 

•  Interpret  operator  inputs 

•  Provide  feedback 


•  Transfer  data  among  communication  nodes 


The  first  function  is  straightforward,  although  generating  the  events  to 
be  displayed  is  a  nontrivial  problem  (see  the  discussion  of  tactical 
situation  models  below).  The  second  function  is  also  relatively  simple 
for  key  press  and  track  ball  entries.  The  process  of  interpreting  voice 
inputs  (automatic  voice  recognition)  involves  some  technical  risk, 
although  recent  technological  advances  have  reduced  the  risk. 

The  problem  of  providing  feedback  to  students  is  relatively  simple, 
given  that  the  performance  measurement  problem  has  already  been 
solved. 

Selecting  lesson  material,  evaluating  performance,  and  providing  feedback 
are  more  difficult  in  the  team  context  than  they  are  for  individual  training 
or  research.  The  technical  difficulty  of  these  functions  stems  primarily 
"rom  the  difficulty  of  developing  the  conceptual  methodology.  Software 
implementation  of  the  solutions  is  probably  within  the  current  state  of  the 
art. 

The  process  of  transferring  data  among  simulation  elements  is  not  a 
difficult  software  problem.  This  capability  will  be  required  for 
simulation  control,  evaluation  of  performance  data,  and  communication 
among  exercise  participants. 

The  difficulty  of  software  development  probably  does  not  vary  significantly 
as  a  function  of  operator  type  (weapons,  surveillance,  battle  staff,  etc). 


Software  to  Support  Functions  of  Exercise  Controllers 


The  personnel  support  modules  for  exercise  controllers,  particularly 
researchers,  should  be  able  to  support  the  following  functions: 

•  Display  visual  information 

•  Interpret  inputs  from  exercise  controllers 

•  Cue  exercise  controllers  when  specified  conditions  or 
events  occur 

•  Reduce  and  process  performance  data 

•  Select  lesson  material 

•  Transfer  data  among  communication  nodes 
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The  first  two  functions  and  the  last  one  are  similar  to  functions  for  AFC 
team  members  and  carry  the  same  low  risk.  Die  difficulty  involved  with 
these  functions  is  related  to  the  problem  of  defining  exactly  what  the 
exercise  controller  should  see  on  the  display,  and  what  functions  are 
required  to  support  exercise  controllers. 

The  ability  of  the  system  to  recognize  specified  conditions  and  events  is 

important.  The  exercise  controller  should  be  able  to  define  the  conditions 

under  which  he  or  she  wishes  to  be  alerted.  One  condition  could  be  when 
2 

an  AFC  team  violates  a  safety  rule,  for  example.  Another  could  be 
successful  completion  of  a  mission  by  a  team.  In  the  first  case  the 
exercise  controller  could  provide  corrective  feedback;  in  the  second 
case  he  or  she  could  give  positive  feedback.  This  capability  would  permit 
the  exercise  controller  to  focus  on  other  events  and  activities — the  filtering 
process  would  be  performed  by  the  software.  The  analysis  required  for 
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implementing  this  function  would  be  complex,  but  the  software  requirements 
for  implementing  the  solution  are  well  within  the  state  of  the  art. 

One  of  the  most  important  software  functions  in  support  of  the  exercise 

controller  would  be  the  automatic  processing  and  presentation  of  individual 

and  team  performance  data  following  an  exercise.  The  technical  difficulty- 

in  this  area  concerns  the  definition  of  just  what  information  should  be 

presented  and  how  it  should  be  formatted.  A  common  problem  with  data 

processing  systems  is  that  they  can  easily  overload  a  user  with 

uncorrelated  information.  The  technical  challenge  (and  risk)  lies  in 

performing  analyses  that  will  measure  what  is  useful,  rather  than  what 

is  available.  These  analyses  are  closely  related  to  the  general  problem 

of  developing  reasonable  performance  measures,  individual  and  team, 

2 

for  operators  in  C  systems. 

The  fifth  function,  the  automatic  selection  of  lesson  material,  would  be 
important  in  research  investigating  various  branching  and  presentation 
strategies  for  computer-assisted  training  programs.  The  capability  to 
select  lesson  material  would  give  a  training  device  much  of  the  power 
and  flexibility  normally  associated  with  CAI. 

The  primary  advantage  is  that  the  training  could  be  adaptive- -the  content 
and  difficulty  of  the  lesson  material  could  be  adapted  to  the  abilities  of 
each  individual  student.  Students  and  teams  could  be  brought  to  criterion 
at  different  rates  and  along  individualized  routes.  Adaptive  training 
depends  on  the  ability  of  the  system  to  evaluate  student  performance. 
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The  major  technical  problem  in  this  area  concerns  performance  assess¬ 
ment  per  se.  It  is  difficult  in  many  situations,  especially  in  emergent 
situations,  to  identify  and  quantify  relevant,  valid,  and  reliable  perform¬ 
ance  continua,  and  to  establish  criteria  for  acceptable  performance. 

Once  this  step  has  been  taken,  the  software  development  required  for 
implementing  the  solution  should  not  be  overly  complex.  The  complexity 
of  various  solutions  cannot  be  assessed  in  advance,  however,  but  must  be 
evaluated  on  a  case-by-case  basis. 

Software  for  Simulation  Models 

Figure  6  lists  several  classes  of  simulation  models  comprising  the  driver 
scenario  for  research  exercises.  The  function  of  these  models  is  to 
generate  the  events  and  contingencies  within  an  exercise.  The  following 
paragraphs  discuss  the  feasibility  of  each  major  type  of  model. 

Voice  Communication  Network  Models --The  definition  of  which  participants 
can  be  called  from  a  given  console  must  be  under  software  control  because 
it  will  vary  widely  from  one  research /training  application  to  another.  A 
system  should  be  developed  so  that  simulation  control  personnel  can 
change  the  definition  conveniently  whenever  necessary.  The  nodes  in  the 
net  should  include  all  participants  in  the  exercise,  as  well  as  the  automatic 
voice  recognition /synthes is  modules.  The  technical  difficulty  of  developing 
software  required  for  implementing  these  functions  is  relatively  low. 

Superteam  and  Subteam  Element  Models --Superteam  elements  must  be 

2 

modeled  whenever  members  of  the  C  team  interact  with  elements  outside 
the  team.  One  superteam  member  is  the  interceptor  pilot.  Modeling  the 
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pilot  appears  to  be  within  the  state  of  the  art,  and  such  a  model  could 
include  automatic  voice  recognition/ synthesis  if  isolated  word  recognition 
capability  proves  adequate.  A  requirement  for  the  speech  recognizer 
to  parse  multiword  utterances  would  increase  the  technical  risk.  More 
complex  superteam  elements  such  as  superordinate  command  organizations 
would  be  much  more  difficult  to  model.  The  primary  difficulty  would  be 
in  defining  superteam  and  subteam  elements,  the  parts  they  play  in  an 
exercise,  and  the  functions  needed  to  execute  these  roles.  In  the  meantime, 
role  players  and  script  readers  offer  a  more  tractable  alternative. 

Own-Aircrew,  Air  Weapons,  and  Sensor  System  Models--This  set  of 
models  should  be  constructed  so  that  the  parameter  values  can  be  modified 
readily.  Examples  of  parameters  that  should  be  modified  are  latency, 
accuracy,  and  response  patterns  of  simulated  pilots,  aircraft  performance 
parameters,  aerial  munitions  parameters,  and  sensor  system  and 
communication  system  capabilities.  The  process  that  is  required  for 
determining  the  appropriate  parameter  values  is  laborious,  but  the 
technique  of  designing  a  model  so  that  parameter  values  can  be  modified 
when  necessary  is  standard  programming  practice. 

Aerial  Combat  Tactics  Models — The  complexity  of  simulating  aircraft 
movements  during  aerial  combat  varies  with  the  number  of  aircraft 
being  simulated,  and  complexity  increases  more  rapidly  than  the  number 
of  aircraft.  For  this  reason,  algorithms  for  simplifying  this  type  of  model 
need  to  be  developed  before  large-scale  engagements  can  be  adequately 
simulated.  It  is  within  the  current  state  of  the  art  to  simulate  small  scale 
engagements  in  detail.  The  dividing  point  between  small-  and  large-scale 
conflicts  may  be  determined  on  the  basis  of  more  complete  analyses. 
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Electronic  Countermeasures  and  Counter- Countermeasures  Models-- 

Electronic  countermeasures  (ECM)  and  counter-countermeasures  (ECCM) 

2 

are  important  features  of  modern  warfare.  C  teams  must  be  proficient 
in  the  detection  and  analysis  of  ECM  that  is  being  directed  against  them, 
and  in  the  use  of  defensive  ECCM  techniques.  Software  capabilities 
that  are  required  to  simulate  electronic  warfare  (EW)  functions  include: 

•  Displaying  the  effects  of  chaff  distribution  and  other  forms 
of  active  radar  jamming 
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•  Displaying  the  effects  of  ECCM  actions  taken  by  the  C  team 
to  counter  radar  jamming 

•  Presenting  the  effects  of  communications  jamming  of  various 

types.  The  presentation  would  be  in  the  form  of  acoustic 

2 

noise  played  over  the  headphones  of  the  C  team  being  jammed. 

In  cases  in  which  external  elements  such  as  intercepter  pilots 

(simulated)  are  being  jammed,  the  effect  would  be  to  reduce 

the  probability  that  the  pilots  would  respond  correctly  to 
2 

inputs  from  the  C  team;  the  pilot  would  either  not  respond  at 
all  or  would  say  "Say  again,  "  for  example. 

•  Responding  realistically  to  ECCM  steps  taken  to  reduce  the 
degree  of  communication  jamming 

Developing  the  models  to  implement  these  functions  will  require  a  major 
analysis  effort  on  the  part  of  EW,  modeling,  and  cognitive  research 
specialists  to  define  the  set  of  required  capabilities  and  the  appropriate 
level  of  fidelity.  The  ECM  and  ECCM  modules  would  be  valuable,  in 
some  cases  essential,  components  of  the  system,  but  they  will  be 
difficult  to  develop. 


Tactical  Situation  Models-- The  models  controlling  the  tactical  situation  may 
be  the  most  difficult  to  define  and  develop.  The  major  software  functions 
required  for  these  models  are: 

•  Accepting  inputs  from  simulation  control  personnel 
regarding  the  initial  conditions  prior  to  an  exercise. 

Initial  conditions  include  the  distribution  and  capabilities 
of  Red  and  Blue  forces,  and  the  general  plan  of  action. 

•  Following  a  preplanned  schedule  until  it  is  modified  by 
exercise  participants. 

•  Receiving  and  responding  to  input  from  role  players  who  are 
acting  as  Red  and  Blue  commanders. 

•  Receiving  and  responding  realistically  to  input  from  the 

,  ,  2 
operators /students  who  are  the  C  team. 

•  Developing  and  sending  to  the  display  processor  information 
about  the  movement  and  disposition  of  all  movers  in  the 
scenario  in  real  time  and  at  variable  rates  both  faster  and 
slower  than  real  time. 

The  first  difficulty  with  these  functions  is  the  analysis  that  is  required  to 
define  the  models  in  detail.  Although  the  process  of  developing  the 
models  is  relatively  difficult,  the  technical  risk  is  low  because  similar 
simulation  and  gaming  capabilities  have  already  been  developed  in  other 
contexts  (some  notable  precedents  are  discussed  later  in  this  chapter) 
and  many  of  the  pertinent  data  exist  in  current  Air  Force  modeling  and 
simulation  systems. 
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A  second  major  problem  Is  to  develop  interactive  software  that  will 

produce  movements  in  real  time  and,  when  research  or  training 

requirements  dictate,  at  rates  other  than  real  time.  One  approach 

that  has  been  taken  in  the  past  is  to  develop  movement  frames  in  an 

off-line  processing  mode  and  then,  during  an  exercise,  presenting  the 

frames  at  the  required  rate.  This  approach  is  appropriate  for  a  variety 

2 

of  applications,  and  is  in  fact  a  computerized  analog  to  the  T  simulation 
system.  The  pre- canned  movements  approach  is  inadequate  for 
applications  that  require  simulated  events  to  be  responsive  to  operator/ 
student  or  researcher/instructor  inputs. 

The  complexity  of  interactive  movement  models  varies  with  the  number 
of  movers  being  portrayed,  and  the  number  of  movers  to  be  portrayed 
depends  on  training  and  research  requirements  that  need  to  be  defined 
for  each  application.  Preliminary  estimates  are  that  the  number  of  target 
elements  that  need  to  be  controlled  interactively  exceeds  the  capabilities 
of  all  current  systems.  The  technical  difficulty  of  developing  tactical 
scenario  models  that  meet  research  and  training  requirements  is  therefore 
relatively  high.  On  the  other  hand,  the  difficulty  of  meeting  an  important 
subset  of  the  requirements  is  low.  The  state  of  the  art  limits  the 
complexity  of  scenarios  that  can  currently  be  portrayed.  Beyond  that  limit, 
advances  in  simulation  technology  will  be  required. 

Software  for  Simulation  of  Tasks  and  Teams 


Simulation  of  tasks  and  teams  in  man-machine  operating  systems  requires 
the  capability  to  represent  them  in  software  as  networks.  The  representation 
has  three  aspects:  1)  models  for  tasks  and  operators  performing  them. 
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2)  combination  of  the  task  models  into  serio- parallel  combinations 
corresponding  to  missions  and  multi- person  groupings,  and  3)  sequential 
dependencies  among  tasks. 

Two  techniques  have  been  developed  to  handle  these  representations: 

The  Siegel-Wolf  modeling  and  the  SAINT  (Systems  Analysis  of  Integrated 

Networks  Tasks)  software  language.  Both  have  been  used  successfully 

in  some  situations.  Although  they  are  still  in  embryonic  stages  of 

2 

development,  they  offer  the  potential  for  simulation  of  C  team  tasks 
in  tactical  missions. 

The  Siegel-Wolf  model  has  been  applied  to  several  problems  in  research 
on  teams:  Communication  as  an  index  of  team  behavior  (Reference  1), 
one-  and  two-operator  systems  (References  2,  3,  and  4),  intermediate-size 
crews  for  aircraft  (References  2  and  5),  performance  of  submarine  crews 
(Reference  6),  and  performance  degradation  of  air  crews  as  a  result  of 
radiation  (Reference  7).  The  model  has  provision  for  workload  and  time 
stress  (Reference  8). 

SAINT  is  a  software  technique  which  extends  the  Siegel-Wolf  approach. 

2 

It  has  also  been  applied  to  C  team  situations  in  AWACS  (Reference  9) 
and  Remotely- Piloted  Vehicle  operations  (Reference  10).  It  has  also  been 
used  in  design  research  for  the  Digital  Avionics  Information  System 
(Reference  11). 
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There  appears  to  be  no  existing  modeling  approach  which  is  adequate 
2 

for  simulation  of  C  teams.  The  evaluation  of  existing  models  was 
summarized  by  Pew,  et  al.  (Reference  12)  as  follows: 

.  .  we  believe  that  integrative  models  of  human  performance 
compatible  with  the  requirements  for  representing  command  and 
control  performance  do  not  exist  at  the  present  time.  What  is 
available  is  a  collection  of  bits  and  pieces  taken  from  a  variety  of 
frameworks  that  might  be  drawn  together  to  build  an  eclectic  model 
for  a  particular  task  situation  of  interest.  The  assembly  of  the 
pieces  will  require  substantial  effort  in  and  of  itself  and  is  likely 
to  require  many  assumptions  about  particular  aspects  of  performance. 
If  one  is  to  have  confidence  in  the  product  so  generated,  several 
iterative  validation  steps  at  different  levels  of  abstraction  will  be 
required.  " 

However,  the  Siegel- Wolf  and  SAINT  approaches  are  considered  the  most 

advanced  techniques  for  representing  networks  of  tasks  and  teams.  They 

2 

require  development  for  applications  to  C  teams.  Nevertheless,  they 
provide  a  technological  base  and  software  framework  on  which  to  build. 

The  SAINT  approach  is  the  more  promising.  It  is  adaptable  to  different 
levels  of  specificity  of  the  activities  in  tasks  and  a  richness  of  performance 
measures.  It  was  designed  to  provide  terminology  for  representing 
multi- person  configurations  and  interactions. 
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The  evaluation  of  SAINT  by  Pew,  et  al.  (Reference  12)  is: 

"As  a  simulation  utility  that  employs  a  bottom-up  approach  to 
performance  prediction,  SAINT  is  probably  without  peer  at  this  time. 

It  incorporates  what  we  consider  to  be  the  most  satisfactory  concepts 
with  respect  to  task  and  operator  parameters  identified  in  SWM, 
and  employs  a  high  level  language  that  is  easily  learned  and  manipulated 
by  the  user.  Further,  the  very  flexible  branching  structure  and  the 
capability  for  changing  the  sequence  of  subsequent  tasks  offer  what 
is  perhaps  a  unique  opportunity  for  the  simulation  of  system  missions 
with  broad  dynamic  range.  " 

We  recommend  an  evaluation  of  SAINT  for  the  purpose  of  describing  teams 
and  team  activities. 

MAJOR  EXISTING  MILITARY  C2T2  SIMULATION  FACILITIES 

Many  simulators  have  been  developed  to  train  individuals  and  teams  to 
2 

perform  C  functions.  Examples  include  the  following: 

•  AW  ACS  simulator 

•  TACFIRE  Trainer  Set  (TTS) 

•  SOT  AS  Ground  Station  Simulator  (SGSS) 

•  Combined  Arms  Tactical  Training  System  (CATTS) 

•  Naval  Warfare  Gaming  System  (NWGS) 
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These  systems  do  not  exhaust  the  relevant  examples  but,  taken  together, 
they  include  most  of  the  functions  described  for  the  prototype  system 
outlined  in  Chapter  II.  Voice  recognition  and  synthesis  are  the  two  notable 
exceptions,  but  these  capabilities  can  be  found  in  other  systems  (for 
example,  the  Navy's  Precision  Approach  Radar  Training  System). 

All  five  systems  listed  above  were  designed  as  training  devices  rather 

than  as  reset-. ’ch  facilities,  although  significant  research  has  been  performed 

on  the  TACFERE  Trainer  Set,  CATTS,  and  the  SOTAS  simulator.  The 

NWGS  is  also  intended  to  support  research.  The  AWACS,  TACFIRE,  and 

SOTAS  simulators  provide  individual  and  team  training  for  operators  of 
2 

complex  C  systems  in  the  Air  Force  and  the  Army.  The  CATTS  and 
NWGS  facilities  were  designed  to  provide  training  in  force  management 
and  tactical  decision-making;  equipment  operation,  per  se,  is  not  a 
primary  concern.  The  AWACS  and  TTS  trainers  are  equipped  with  operational 
equipment  driven  by  simulation  software.  The  other  systems  consist 
primarily  of  off-the-shelf  equipment. 

The  following  discussion  presents  a  high-level  overview  of  the  functions 
and  capabilities  of  each  system  listed  above,  and  emphasizes  the  features 
that  are  most  relevant  in  the  present  context.  The  theme  of  the  discussion 
is  that  the  technical  risk  associated  with  various  features  of  the  prototype 
is  within  reasonable  bounds  if  similar  features  have  been  implemented  in 
existing  systems. 
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AWACS  Simulator 


The  hardware  comprising  the  AWACS  simulator,  at  Tinker  AFB,  is  quite 

2  2 

similar  to  that  proposed  in  Chapter  II  for  the  AFC  T  research  facility. 

The  simulator  includes  nine  student  stations  and  several  other  support  stations. 
The  student  stations  are  actual  operational  situation  displays  driven  by 
simulation  software.  As  in  the  operational  system,  the  student  consoles 
can  be  reconfigured  to  support  battle  staff,  weapons,  or  surveillance 
functions.  The  support  stations  include  a  Computer  and  Display 
Maintenance  Operator  (CDMO)  console  and,  in  an  adjacent  room, 
simulation  control  consoles.  The  CDMO  station  functions  primarily  as 
a  simulation  control  station,  and  is  not  typically  involved  in  actual 
exercises. 

Operator  consoles  include  displays,  function  keys  and  switches,  an 
alphanumeric  keyboard,  track  ball,  and  communication  gear.  The 
physical  fidelity  of  the  consoles  is  high  because  operational  gear  is  used. 

The  AWACS  simulator  hardware  does  not  include  large- screen  displays 
or  automatic  voice  recognition/synthesis  capabilities. 

The  software  driving  the  AWACS  simulator  performs  many  of  the  functions 
recommended  for  the  prototype  research /training  simulator.  Visual 
imagery  comparable  to  real-world  imagery  is  displayed  to  the  operators, 
and  the  function  keys  operate  as  they  do  in  the  actual  system.  The 
functional  fidelity  of  actions  is  enforced  by  the  fact  that  the  simulator 
software  is  under  the  same  strict  configuration  management  system  that 
controls  the  airborne  software. 
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The  careful  control  of  the  airborne  software  is  understandable  given  the 
risks  involved  in  actual  operation.  The  unfortunate  consequence  of 
controlling  the  simulator  software  as  closely  is  that  it  is  apparently  very 
difficult  to  implement  changes  that  would  improve  the  utility  of  the 
simulator  as  a  training  or  research  device.  Needed  changes  or  additions 
suggested  by  system  users  are  listed  below: 

•  Interceptor  pilots  should  be  simulated.  Software  to  control 

2 

the  tracks  and  provide  verbal  responses  and  inputs  for  the  AFC 
team  should  be  developed. 

•  Performance  assessment  routines  should  be  automated. 

Instructors  should  not  be  restricted  to  looking  over  the 
shoulders  of  students  and  providing  verbal  guidance  and  feedback. 

•  Performance  data  should  be  collected  during  an  exercise  and 
printed  out  for  the  instructor  at  the  end  for  post- mission 
evaluations. 

•  Superteam  elements  should  be  modeled. 

•  It  should  be  more  feasible  to  tie  the  simulator  to  other  nodes 

2 

in  a  C  network. 

•  The  simulator  should  be  responsive  to  ECM  and  ECCM  inputs. 
Several  respondents  remarked  during  our  interviews  that  such  a 
capability  would  be  valuable,  especially  for  the  surveillance 
subteam.  They  felt  that  it  should  be  possible  to  introduce  EW 
problems  into  an  exercise  and  train  the  operators  to  deal  with 
them.  The  simulator  currently  does  not  display  such  interference 
and  does  not  respond  when  operators  make  corrective  inputs. 
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Changes  in  radar  mode,  for  example,  do  not  change  simulated 
imagery  even  though  actual  imagery  would  change. 

SEPPs  have  been  developed  to  provide  exercises  of  various  levels  of 

difficulty  in  various  parts  of  the  world.  A  set  of  exercises  exist  for  a  Mid- 

East  airspace,  for  example,  and  the  exercises  are  graded  to  expose  the 

students  to  a  variety  of  situations  at  several  levels  of  intensity.  The 

2 

SEPPs  are  good  attempts  to  explore  the  AFC  problem  space,  but  they  have 
several  major  drawbacks: 

•  They  are  difficult  to  modify  and  are  therefore  typically 
outdated. 

•  The  procedures  for  modifying  a  SEPP  exercise  require  resources 
and  expertise  that  are  typically  not  available.  This  situation 
underscores  the  design  criterion  that  the  tactical  situation  fnodels 
in  the  prototype  research/training  simulator  should  be  readily 
modifiable  by  personnel  who  are  not  software  professionals. 

•  The  SEPP  scenarios  are  not  interactive  to  the  extent  recommended 

in  Chapter  II.  The  software  actually  stimulates  the  operating 

system  to  produce  simulated  air  traffic  returns.  These  returns 

2 

are  precanned  and  noninteractive,  except  that  AFC  team 
members  can  attach  track  labels  to  the  returns  as  they  would  in 
the  operational  system.  Interactively  controlled  tracks  can  be 
overlaid  or  masked  with  this  background.  These  tracks,  which 
are  similar  to  T-4  tracks,  are  controlled  by  exercise  controllers 
and  role  players,  and  can  be  used  for  intercept  exercises  and 
bump-heads  free-play,  but  they  cannot  currently  be  used  to 
simulate  larger-scale,  two-sided,  free-play  engagements. 
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•  All  knowledge  of  aerial  combat  tactics  resides  in  the  exercise 
controllers  and  role  players  rather  than  the  software. 

T  AC  FIRE  Trainer  Set  (TTS) 

The  TTS.  which  is  operated  by  the  US  Army  Field  Artillery  School  at 
Fort  Sill,  consists  of  over  a  dozen  TACFIRE  terminals  driven  by  a 
TACFIRE  computer.  The  terminals  are  artillery  control  consoles  (ACCs) 
and/or  variable-format  message  entry  devices  (VFMEDs).  The  precise 
number  of  each  type  of  terminal  is  a  variable  that  depends  on  training 
objectives  and  lesson  plans. 

The  consoles  consist  of  small  CRT  screens,  function  keys,  and  an 
alphanumeric  keyboard.  Only  alphanumeric  characters  are  presented  on 
the  displays;  the  terminals  have  no  graphics  capability.  The  TTS  uses 
operational  equipment,  so  physical  fidelity  is  not  an  issue. 

The  TTS  uses  no  large- screen  displays,  but  it  does  incorporate  a  digital 
plotter  map  (a  large  X-Y  plotter)  that  prints  hard  copies  of  geometrical 
information. 

The  TTS  is  not  hampered  by  the  software  constraints  discussed  for  the 
AWACS  simulator.  Rather,  the  operational  software  is  flushed  out 
completely  and  is  replaced  by  lesson  modules  written  in  PLANIT 
(References  13  and  14).  The  lesson  modules  are  written  to  make  the 
system  look  to  the  operator  as  if  he  is  interacting  with  the  actual  TACFIRE 
system.  The  advantage  of  using  PLANIT  is  that  operator  performance 
can  be  monitored  objectively,  quantitatively,  and  accurately.  Feedback 
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can  be  directed  to  the  student  whenever  he  makes  an  error  or  performs 
well.  The  operator  can  be  branched  to  more  complex  material  or  looped 
back  through  remedial  material,  depending  on  his  performance.  PLANIT 
makes  detailed  performance  records  available  to  the  researcher/instructor 
whenever  requested.  The  type  and  amount  of  detail  can  be  tailored  to 
the  requirements  of  specific  research  or  training  applications. 

The  Army  Research  Institute  (ARI)  has  sponsored  excellent  work  to  test 
the  utility  of  PLANIT  for  team  training  in  the  T  AC  FIRE  context 
(References  15  through  19).  PLANIT  essentially  acts  as  a  buffer  between 
team  members.  PLANIT  can  check  messages  sent  from  one  operator  to 
another  for  accuracy  before  they  are  actually  transmitted.  Feedback  can 
then  be  sent  to  the  first  operator  as  a  corrected  message  is  sent  to  the 
second.  PLANIT  can  also  monitor  team  processes  and  identify  steps  that 
are  taking  too  long.  Feedback  can  be  issued  directly  to  the  operators  and/or 

the  instructor  can  be  summoned  for  assistance.  Such  an  approach  could 

2  2  2 
be  followed  in  AFC  T  research  and  training,  although  AFC  systems 

rely  more  on  voice  communication  and  less  on  digital  messages  than  is  the 

case  in  TACFIRE. 

TACFIRE  is  well-suited  to  the  frame-oriented  CAI  approach  of  PLANIT. 

2 

PLANIT  may  also  be  appropriate  for  the  AFC  research  and  training 

environment  as  well,  although  the  fit  may  not  be  as  close.  The  imagery 

2 

requirements  of  AFC  displays  may  be  difficult  in  PLANIT,  but  recent 
advances  have  improved  the  graphics  capabilities  of  PLANIT. 
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The  TTS  is  not  particularly  well- suited  for  war  gaming  exercises.  Its 
focus  is  on  providing  basic  skills  training  for  TACFIRE  operators  and 
teams,  and  artillery  tactics  are  taught  elsewhere. 

SOTAS  Ground  Station  Simulator  (SGSS) 


The  SGSS  is  designed  to  support  training  and  human  factors  research  for 
the  engineering  development  model  of  the  SOTAS.  The  SGSS  is  the  latest 
in  a  series  of  SOTAS  simulators  designed  and  built  by  Honeywell's 
Systems  and  Research  Center  under  contract  to  PM  SOTAS. 

The  SGSS  includes  10  operator  consoles,  three  instructor  control  stations, 
and  a  bank  of  minicomputers  with  associated  peripherals.  The  SGSS 
departs  from  the  tradition  of  the  AWACS  and  TTS  simulators  in  that 
commercial,  off-the-shelf  equipment  was  used  in  its  construction.  It  is 
driven  by  20  minicomputers,  two  for  each  student  console,  rather  than  by 
a  single  mainframe  computer.  Among  other  advantages,  this  distributed 
processing  approach  reduces  the  probability  that  hardware  problems  will 
cause  all  consoles  to  fail  simultaneously. 

The  use  of  commercial  equipment  reduced  both  the  initial  cost  of  the 
system  and  the  lead  time  required  to  obtain  major  units.  It  also  enabled 
system  designers  to  tailor  the  hardware  and  software  configuration  to  a 
training  and  research  environment,  as  opposed  to  an  operational  field 
setting. 

Each  instructor  control  station  includes  a  CRT  screen,  keyboard,  and 
communication  control  panel  that  allow  instructors  to  define  lessons. 
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monitor  student  progress,  and  establish  voice  contact  with  specific 
students.  In  addition,  an  instructor  can  play  the  role  of  external  superteam 
members. 

Student  consoles  consist  of  imagery  displays,  function  keys,  an  alpha¬ 
numeric  keyboard,  track  ball,  radio,  and  intercom  gear.  As  in  the 
operational  system,  a  console  can  be  reconfigured  to  support  any  of  the 
,  four  major  types  of  SOTAS  ground  station  operators.  The  consoles  are 

configured  to  look  like  operational  equipment,  and  are  installed  in  rooms 
that  match  the  size  and  shape  of  the  truck-mounted  SOTAS  vans. 

k  The  imagery  for  operator  displays  is  generated  off-line  and  is  stored, 

> 

frame  by  frame,  for  presentation  during  exercises.  The  scenario  is 
precanned  and  noninteractive.  The  scenario  includes  only  Red  force 
|  elements.  Blue  force  elements  are  not  currently  portrayed.  Users  can 

decide  which  portion  of  the  material  to  view  and  can  vary  the  viewing 
mode  freely,  so  the  system  is  interactive  in  that  sense,  but  it  does  not 
support  war  gaming  functions  such  as  those  recommended  for  the 
prototype  research/training  simulator. 

Operator  procedures  (that  is,  key  press  sequences)  are  functionally 
equivalent  in  the  operational  system  and  the  SGSS.  The  SGSS  software 
was  built  with  the  flexibility  to  test  alternative  procedures,  however,  so 
the  SGSS  functions  both  as  a  trainer  and  as  a  human  factors  research  tool. 
The  flexibility  inherent  in  the  software  design  also  permits  the  development 
of  performance  measurement  routines  and  instructor  aids. 


Combined  Arms  Tactical  Training  System  (CATTS) 

CATTS  is  an  impressive  simulation  facility  that  has  been  in  use  at 
Fort  Leavenworth  for  approximately  five  years  (References  20,  21,  22). 

The  purpose  of  CATTS  is  to  provide  simulated  combat  experience  for 
battalion  command  groups.  The  commani  group  is  situated  in  one  of  two 
environments,  either  the  main  command  post  (a  simulated  tent)  or  a 
tactical  command  post  (a  simulated  armored  personnel  carrier).  The 
command  groups  are  equipped  with  communication  equipment  (radios  and 
field  telephones),  maps,  and  grease  pencils. 

CATTS  currently  simulates  battles  in  German  and  Mideast  environments. 
Other  geographical  areas  could  also  be  simulated  provided  that  the  data 
were  available  and  the  analyses  were  performed.  The  principal  data  sets 
that  change  with  location  are  intervisibility,  movement  rates,  and  Red  and 
Blue  force  structures.  Within  a  particular  environment,  CATTS  is 
essentially  a  two-sided,  free-play  war  gaming  system  in  which  the  Blue 
forces  are  commanded  by  the  battalion  command  group  and  the  Red 
forces  are  commanded  by  the  exercise  controllers. 

The  physical  fidelity  of  the  equipment  and  surroundings  is  high.  The 
main  and  tactical  command  posts  actually  look  like  the  interior  of  a  tent 
or  armored  personnel  carrier.  Standard  tactical  maps  are  used,  and  the 
shells  of  actual  radio  and  telephone  sets  are  tied  into  the  computer  and 
control  rooms.  Audio  speakers  present  the  sound  of  incoming  and  outgoing 
artillery  fire,  and  the  loudness  and  frequency  of  the  concussions  varies  with 
the  intensity  of  the  battle  and  its  distance  from  the  command  post. 
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Communications  jamming  is  simulated  by  adding  computer- generated  noise 
to  the  voice  signals  going  from  the  control  center  to  the  command  group. 


The  communication  equipment  feeds  into  a  control  room  that  is  staffed 
by  simulation  controllers  who  monitor  Blue  force  movements  and  control 
Red  force  movements.  The  battalion  command  group  is  in  control  of 
several  companies.  All  information  about  Red  movements  and  the 
condition  of  Blue  forces  gets  to  the  command  group  in  the  form  of  reports 
from  the  simulation  controllers,  who  play  the  role  of  company  commanders. 
The  controllers  move  the  Blue  units  as  directed  by  the  battalion  commander 
but  within  the  constraints  of  the  scenario.  They  then  move  Red  units  to 
apply  as  much  pressure  on  the  Blue  force  as  they  feel  is  appropriate. 

The  battalion  command  group  is  fighting  an  essentially  omniscient  enemy. 

CATTS  software  and  hardware  do  not  drive  operator  displays  or  equipment 
because  there  is  no  such  equipment  in  the  battalion  command  post.  Instead, 
an  extensive  support  system  has  been  developed  to  aid  the  simulation 
controllers.  The  software  includes  movement,  terrain,  weather,  engage¬ 
ment,  and  other  relevant  tactical  models  that  compute  unit  positions  and 
engagement  outcomes.  Hardware  includes  consoles  for  Blue  and  Red 
controllers  and  software  management,  a  mainframe  computer,  and 
peripheral  equipment.  The  software  and  hardware  support  displays  and 
procedures  that  allow  the  simulation  controllers  to  enter  Red  and  Blue 
movement  commands,  monitor  movements,  and  keep  track  of  engagement 
outcomes. 


75 


CATTS  provides  little  performance  assessment  or  data  collection  support 
for  researchers  or  instructors.  Instructors  view  the  action  and  can  provide 
feedback  to  the  command  team  during  the  exercise  if  appropriate.  More 
often,  feedback  is  provided  during  debriefings  following  the  multiday 
exercises.  Individual  and  team  performance  data  are  collected  in  the  form 
of  videotapes  that  record  command  group  behavior.  The  videotape  system 
is  independent  of  the  computer  system,  however,  so  attempts  to  correlate 
behavioral  events  with  software  events  are  laborious. 

Naval  Warfare  Gaming  System  (NWGS) 

The  NWGS  is  currently  under  development  and  will  be  delivered  to  the 
US  Naval  War  College  when  completed.  The  detailed  statement  of 
requirements  (References  23,  24,  25)  called  for  a  computerized  system 
to  provide  training  in  tactical  command  decision-making  for  students  and 
for  operational  command  staffs.  The  system  will  consist  of  a  number 
of  terminals  tied  to  a  time-sharing  computer.  The  terminals  will  present 
alphanumeric  and  graphic  information  on  CRT  screens,  and  will  also  be 
able  to  provide  hard  copies  of  the  displayed  information.  Umpires  will 
have  large- screen  displays  depicting  the  tactical  situation. 

The  primary  function  of  the  software  will  be  to  automate  many  of  the 
functions  that  have  typically  been  performed  by  experts  operating 
and  observing  a  manual  war  game; 

•  Movement  of  tactical  units 

•  Sensor  reports 
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•  Electronic  and  acoustics  support  and  countermeasures  effects 

•  Weapons  effects  and  battle  damage  assessment 

•  Supply  levels  and  logistics  procedures 

•  Own  and  threat  tactical  doctrine 

Instead  of  using  the  above  types  of  information  directly,  the  umpires  will 
monitor  events  and  make  inputs  only  when  they  judge  that  it  is  necessary 
to  do  so.  Umpires  will  also  have  the  capability  to  change  the  game  rate  to 
rates  other  than  real-time  (faster  or  slower,  as  appropriate),  and  make 
discrete  time  steps  in  either  direction.  They  may  replay  events  to 
provide  feedback  for  participants,  or  go  forward  to  bypass  periods  of 
low  activity. 

The  NWGS  will  support  a  wide  range  of  games  (Reference  26).  The 
primary  categories  of  games  will  be: 

•  Weapon- system- level  games  —  These  games  will  enable  individuals 
and  small  groups  of  students  to  study  the  capabilities  of  specific 
naval  weapons  and  sensor  systems  and  the  effects  of  changes 

in  system  parameters. 

•  One-on-one  engagement  level  games- -These  games  will  be 
characterized  by  relatively  limited  areas  of  operations  and  short 
periods  of  play.  The  games  will  be  used  for  analyzing 
engagements  between  tactical  units  (for  example,  submarine  vs 
submarine,  ASW  aircraft  vs  submarine,  attack  aircraft  vs 
surface  ship). 
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•  Full-scale  games--These  games  will  be  at  the  task  force  level, 
and  will  cover  relatively  large,  perhaps  global,  areas  of 
operation. 

There  will  be  three  types  of  one-on-one  engagement  level  games:  Pre¬ 
programmed,  computer-opposed,  and  free- play.  Preprogrammed  games 
will  be  a  form  of  CAI  in  which  the  computer  will  lead  the  participants 
through  a  preplanned  set  of  decision  points  and  give  feedback  following 
each  decision.  In  computer-opposed  games,  the  participants  will  control 
the  Blue  forces  and  the  computer  will  follow  threat  doctrine  in  controlling 
Red  forces.  In  free-play  games,  two  groups  of  participants  will  oppose 
each  other. 

Full-scale  games  will  be  one-sided  (computer-opposed)  or  two-sided 
(free-play). 

Games  of  any  of  the  three  types  may  be  played  at  several  levels.  Individuals 
or  small  groups  of  students  will  be  able  to  play  small-scale  games  and 
serve  as  their  own  umpires.  Large,  full-scale  games  will  involve  numerous 
groups  of  participants  and  several  umpires.  All  groups  and  umpires  will 
be  able  to  communicate  individually  and  by  voice.  Because  the  NWGS  will 
be  run  by  a  time-sharing  system,  several  independent  small-scale  games 
may  be  played  simultaneously. 

The  software  comprising  the  driver  scenario  for  the  games  will  consist  of 
the  following  major  modules: 
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•  Platform  (surface  craft,  subsurface  craft,  fixed-  and  rotary-wing 
aircraft,  spacecraft,  shore  installations).  Platform  characteristics 
include  motion  capabilities,  fuel  capacity  and  consumption  rates, 
electronic  and  weapons  systems,  and  so  forth. 

•  Electronic  systems  (sensors,  communications) 

•  Weapon  systems  (rate  of  fire,  range,  reliability,  hit  probability, 
kill  probability) 

•  Logistics  (amounts  of  consumables,  rate  of  consumption,  and 
resupply  rate) 

The  majority  of  forces  will  usually  be  divided  between  two  opposing  sides. 
Forces  may,  however,  also  be  assigned  to  nations  or  blocs  friendly  to  one 
or  the  other  major  contestants  and/or  neutral  nations  and  blocs. 

Games  will  frequently  require  many  tactical  elements.  A  tactical  element 
is  a  platform  or  system  that  is  controlled  as  a  unit  in  the  scenario.  It  may 
consist  of  several  elements  in  some  cases;  a  flight  of  nine  aircraft  on 
the  same  mission  may  be  considered  as  a  single  element,  for  example, 
rather  than  as  nine  elements.  Elements  are  further  classified  into  sets, 
formations,  aggregations,  patterns,  and  movement  plans.  The  specified 
minimum  number  of  units  to  be  supported  by  the  NWGS  is: 


Commands 

2000 

Sets 

1500 

Formations 

100 

Aggregations 

100 

Patterns 

200 

Movement  Plans 

200 
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The  software  will  consist  of  models  and  a  data  base.  The  data  base  will  be 
modifiable  by  authorized  personnel  who  are  not  computer  professionals. 
Modification  of  the  data  base  will  not  affect  the  structure  or  function  of 
the  models. 

The  terminals  used  by  participants  and  instructors  will  not  resemble 
operational  naval  equipment.  They  will  be  designed  to  present  the  type 
of  information  that  is  normally  available  for  tactical  decision-making,  but 
the  manner  of  presentation  will  not  match  any  current  systems. 

The  NWGS  is  currently  being  built  by  Computer  Sciences  Corporation  using 
a  Honeywell  Multics  computer  system. 


The  NWGS  is  the  largest  war  gaming  simulation  with  man- in- the -loop 
which  has  been  attempted  to  date.  The  results  of  the  design  phase  of  the 
program  showed  it  to  be  within  the  attainable  state  of  the  art. 

Summary 

The  above  examples  illustrate  that  the  hardware  requirements  for  the 

prototype  research /training  device  are  well  within  the  state  of  the  art. 

The  SGSS  and  NWGS  are  important  in  this  context  because  they  consist  of 

commercial  equipment.  CATTS  also  uses  commercial  equipment  although 

2 

the  equipment  does  not  interface  with  C  personnel  directly. 
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Many  of  the  recommended  software  capabilities  are  also  illustrated.  The 
AWACS  and  SOTAS  simulators  are  capable  of  displaying  realistic  radar 
imagery  depicting  complex  tactical  situations.  They  and  the  TTS  can  receive 
and  process  operator  inputs  through  function  keys  and  other  control  devices, 
and  produce  realistic  responses.  The  SGSS  and  TTS  incorporate  many 
advanced  features  for  measuring  individual  and  team  performance,  and 
provide  performance  data  to  researcher/ instructors.  The  SGSS,  TTS 
and  AWACS  simulators  all  provide  a  measure  of  reconfigurability:  the 
consoles  can  support  various  classes  of  operators  and,  in  the  TTS,  the 
mix  of  console  types  can  be  modified  to  meet  special  training  requirements. 
CATTS,  the  SGSS,  and  to  a  lesser  extent  the  AWACS  simulator,  encourage 
the  use  of  role  players  to  provide  superteam  training.  CATTS  and  the 
NWGS  come  the  closest  to  providing  the  flexible,  two-sided  war-gaming 
capability  and  EW  features  recommended  in  Chapter  II. 

One  of  the  most  important  lessons  of  the  examples  is  that  the  scenario 
generation  process  is  extremely  difficult.  It  requires  extensive  data  on 
system  capabilities,  operational  procedures,  and  decision  processes  and 
criteria,  and  the  data  are  often  very  difficult  to  obtain.  The  AWACS  SEPPs, 
TTS  problems,  and  CATTS,  NWGS,  and  SOTAS  scenarios  all  require  a 
substantial  effort  to  develop,  and  will  require  a  significant  continuing 
effort  to  keep  updated.  Once  the  data  have  been  revised,  the  scenarios  must 
be  entered  into  the  software  system.  This  is  often  a  difficult  task  in  itself, 
although  the  SGSS,  CATTS,  and  the  NWGS  have  been  designed  to  facilitate 
such  changes. 
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RECOMMENDATION 


2  2 

The  recommended  AFC  T  research  facility  should  be  designed  by 

incorporating  the  best  features  of  the  simulators  described  above,  as 

well  as  the  SAINT  language.  The  integration  of  these  design  features 

2  2 

should  proceed  in  parallel  with  an  analysis  of  specific  AFC  T  applications 

2  2 

and  the  research  designs  of  specific  AFC  T  studies.  The  number  of 
applications  and  studies  should  be  limited  to  as  few  as  possible  to  keep  the 
analysis  manageable,  but  should  also  represent  a  domain  of  problems  or 
issues  so  that  growth  and  expansion  of  the  research  effort  will  be  possible 
without  major  changes  in  resource  requirements  or  direction.  Research 
issues  to  be  addressed  through  the  use  of  the  recommended  facility  are 
discussed  in  Volumes  II  and  III,  and  are  summarized  in  the  following 
chapter. 
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CHAPTER  V 


RESEARCH  APPLICATIONS 

2  2 

The  recommended  AFC  T  research  facility  will  be  used  to  support 
empirical  research  into  a  variety  of  areas,  as  summarized  in  Table  1. 

The  facility  would  consist  of  the  hardware  and  software  modules  discussed 
in  Chapter  II.  These  modules  are  summarized  in  Table  2.  The  technical 
difficulty  of  developing  each  module,  as  discussed  in  Chapter  IV,  is  also 
shown  in  the  table. 

Not  all  modules  are  required  for  all  research  projects.  By  identifying  the 

minimum  set  of  features  required  for  preliminary  research  in  each  area, 

a  simulator  development  plan  can  be  formulated.  Low-risk  features 

required  for  a  large  number  of  high-priority  research  projects  should  be 

designed  and  procured  early  in  the  simulator  acquisition  cycle.  High-risk 

features  that  are  required  for  a  smaller  number  of  lower-priority  research 

projects  should  be  deferred  until  later.  This  developmental  strategy 

2  2 

increases  the  probability  for  an  early  payoff--in  the  form  of  C  T  research 
data--while  ensuring  that  the  system  can  grow  to  meet  future  research  needs. 

The  following  sections  briefly  summarize  each  of  the  issues  listed  in 
Table  1,  and  indicate  the  simulation  capabilities  that  would  be  most 
valuable  during  the  initial  phases  of  research  on  each  topic. 

The  chapter  concludes  with  a  prioritized  list  of  simulation  capabilities 

2  2 

required  for  empirical  C  T  research. 
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TABLE  2.  MAJOR  HARDWARE  AND  SOFTWARE  MODULES  FOR 
THE  RECOMMENDED  AFC2T2  RESEARCH  FACILITY 


Technical 

Module 

Difficulty 

User  control  consoles 

L 

Processing  equipment 

L 

C-  communication  network  model 

M 

Subteam  models 

M 

Superteam  models 

H 

Own- aircrew  modeLs 

M 

Aerial  combat  tactics  models 

H 

Air  weapons  models 

L 

Sensor  systems  models 

L 

ECM/ECCM  models 

H 

Tactical  situation  models 

H 

Training  support  functions 

H 

Level  of  technical  difficulty  (as  discussed  in  Chapter  IV): 

L  -  Low,  M  =  Medium,  H  =  High 

PERFORMANCE  MEASUREMENT  FOR  C2  OPERATORS.  TEAMS,  AND 
SYSTEMS 


The  set  of  performance  measurement  problems  should  receive  the  highest 
priority  research  attention  because  so  many  other  issues  depend  on  the 
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existence  of  quantitative,  reliable,  valid,  automated  performance  measure¬ 
ment  techniques.  The  performance  measurement  issues  have  been 
organized  into  four  groups: 

•  Individual-- What  product  and  process  measures  characterize 

2 

the  performance  of  individual  C  team  members  ? 

•  Team--What  product  and  process  measures  characterize 

2 

the  performance  of  C  teams  ? 

2 

•  System  Effectiveness--How  can  C  system  effectiveness 
in  a  tactical  environment  be  assessed  ? 

•  Contribution  of  Individual  and  Team  Performance  to  System 

2 

Effectiveness- -What  proportion  of  variance  in  C  system 
effectiveness  is  accounted  for  by  individual  and  team  performance? 

The  minimum  simulator  capabilities  required  to  begin  addressing  these 
problems  are  summarized  in  Table  3. 

c2t2  PROGRAM  OBJECTIVES  AND  REQUIREMENTS 

The  recommended  research  facility  can  be  used  as  one  tool  in  the  analysis 
2  2 

of  C  T  program  objectives  and  requirements.  Four  research  topics 
of  this  type  that  could  be  explored  through  the  use  of  the  research  facility 
are: 

•  Media  Selection  Analysls--Which  skills  and  procedures  are 
best  trained  through  simulation  exercises  ? 
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Sequencing  of  Instructional  Material--In  what  order  and  at 
what  level  of  detail  should  simulation  exercises  treat  course 
topics  ? 


•  Interaction  of  Team  Type  and  Task  Type  with  Instructional 
Strategy-- What  are  the  most  effective  strategies  to  be  used 
in  applying  simulation  exercises  to  various  types  and  levels 
of  teams  and  various  task  types  ? 

•  Development  of  Representative  Problem  Sets-- What  are  the 
features  of  effective  tactical  problems  and  how  should  they 
be  presented  ? 

Minimum  simulator  capabilities  required  to  begin  addressing  these 
problems  are  summarized  in  Table  4. 

CV  SIMULATION  EXERCISE  REQUIREMENTS 

The  research  facility  could  be  used  In  assessing  procedures  for  determining 
exercise  requirements  for  a  variety  of  training  contexts.  Research 
projects  and  issues  that  would  benefit  from  the  use  of  the  facility  are: 

•  Definition  of  Training  Requirements  for  Simulation  Exercises-- 
What  simulation  facilities  and  capabilities  are  required  for 
meeting  various  training  objectives  ? 

•  Physical  Fidelity- -What  are  the  important  determinants  of 
physical  fidelity,  and  what  level  of  physical  fidelity  is  required 
for  various  applications  ? 
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TABLE  4.  MINIMUM  SET  OF  SIMULATION  MODULES  REQUIRED  TO  SUPPORT 
RESEARCH  IN  C2T2  PROGRAM  OBJECTIVES  AND  REQUIREMENTS 


_ 

» 

co 

03 

«-* 

<0 

C 

c 

0) 

0 

ai 

Of] 

a 

CO 

>> 

a> 

3 

<-» 

DO 

u 

03 

C 

co 

v- 

: / ) 

& 

CO 

£ 

CJ 

CO 

a 

<D 

U 

(0 

c 

0 

c 

0/ 

£ 

w* 

w 

CO 

0 

CO 

V-r 

8L 

o 

0 

0 

co 

c 

e 

o£ 

c 

>> 

c 

<u 

03 

cn 

C  ^ 

o  *5 

.2 
■*— » 

0 

•*< 

£ 

a 

5 

d  T 

u 

U) 

u 

0 

u 

03 

^ 

5  o> 

co 

co 

3 

O. 

•H 

&- 

■*-* 

T 

"O 

ST  n 

-o 

to 

> 

0/ 

25 

o>  c 
t/}  c 

c 

c 

03 

c 

Q 

• 

• 

• 

• 

rtial 

pahil 


•  Tactical  Fidelity- -What  are  the  important  determinants 
of  tactical  fidelity,  and  what  level  of  tactical  fidelity 

is  required  for  various  applications  ? 

•  Automated  Operator  and  Team  Performance  Assessment- -What 
performance  measurement  capabilities  can  be  incorporated 
into  simulation  exercises  and  what  are  the  benefits  of  doing 
so? 

•  Feedback  Techniques- -What  are  the  most  effective  ways  to 

2 

provide  performance  feedback  to  C  operators  and  teams  during 
simulation  exercises  ? 

•  War  Gaming — To  what  extent  should  two-sided,  free-play 
war-gaming  capabilities  be  incorporated  into  simulation 
exercises,  and  what  are  the  best  techniques  for  doing  so? 

•  Part- Whole  Task  Exercises-- What  advantages  and  economies 
can  be  achieved  by  developing  a  set  of  exercises  that  treat 
parts  of  the  operator  or  team  task  rather  than  one  exercise 
that  attempts  to  cover  the  entire  task? 

Minimum  simulator  capabilities  required  to  begin  assessing  these  problems 
are  summarized  in  Table  5. 

MAN- MACHINE  DESIGN  FOR  C2  SYSTEMS 

The  recommended  research  facility  has  the  potential  for  serving  as  a  test 

2 

bed  for  system  developers  in  the  early  stages  of  acquiring  new  C  systems. 
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Issues  that  could  be  treated  during  this  process  are: 


•  Interaction  of  Team  Type  and  Task  Type--What  team  types  and 

2 

structures  are  most  appropriate  for  the  types  of  C  tasks/ 
functions  to  be  performed  by  the  system? 

•  Information  Flow  Analysis--What  are  the  inputs  to  and  outputs 
from  the  system,  and  how  is  the  information  to  be  processed 
by  the  components  and  personnel  within  the  system? 

•  Functional  A  [location- -Which  functions  should  be  allocated  to 
hardware  and  software  components  and  which  to  personnel; 
how  should  the  personnel  functions  be  allocated  among  sub¬ 
teams  and  individuals  ? 

•  Operator  and  Team  Decision  Aids--What  types  of  decision  aids 
should  be  developed  for  operators  and  teams,  and  how  will  they 
affect  performance  ? 

•  Operator  and  Team  Consoles,  Communication  Nets,  and  Proce¬ 
dures- -How  should  these  items  be  designed  to  maximize  system 
effectiveness  ? 

Minimum  simulator  capabilities  required  to  begin  assessing  these  problems 
are  summarized  in  Table  6. 

AUTOMATED  C2T2  TRAINING  SUPPORT  FUNCTIONS 

As  discussed  in  Chapter  III,  automated  training  support  functions  offer 
the  potential  for  improving  the  quality  of  instructional  programs  and 
the  efficiency  of  instructor  time.  Specific  research  areas  that  need 
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to  be  addressed  are: 


•  Assessment  of  Operator  and  Team  Performance- -What  are 
the  most  effective  procedures  for  assessing  student  and  team 
performance  during  training  ? 

•  Maintenance  of  Performance  Records-- What  are  the  most 
appropriate  records  to  store,  how  should  they  be  organized, 
and  how  should  instructional  personnel  gain  access  to  them? 

•  Control  of  Lesson  and  Exercise  Sequencing--What  methods 
can  be  developed  for  sequencing  instructional  events  on  the 
basis  of  student  and  team  performance? 

•  Adaptive  Training  and  Testing- -How  can  training  systems 
adapt  the  level  and  pacing  of  instructional  events  to  student 
team  performance,  and  what  is  the  payoff  for  doing  so? 

•  Monitoring  and  Guidance  of  Student  Performance- -What  automated 
techniques  can  be  developed  to  guide  students  and  teams  through 
instructional  programs,  and  what  effect  will  these  techniques 
have  on  the  productivity  of  training  programs  ? 

Minimum  simulator  capabilities  required  to  begin  addressing  these  problems 

are  summarized  in  Table  7. 

PERSONNEL  REQUIREMENTS  FOR  C2  TEAMS 

The  research  facility  can  be  used  in  assessing  personnel  requirements 

2 

for  C  teams.  Specific  issues  are: 

•  Prerequisite  Skill  and  Knowledge  Requirements--Can  the  requirement 

■  - -  2 

for  specific  aptitude,  skills,  and  knowledge  for  C  team  members 

be  demonstrated  empirically? 
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TABLE  7.  MINIMUM  SET  OF  SIMULATION  MODULES  REQUIRED  TO  SUPPOR1 
RESEARCH  IN  AUTOMATED  C^T^  TRAINING  SUPPORT  FUNCTIONS 


•  Remediation  Techniques --If  entry-level  students  are  deficient 
in  prerequisite  skills  and  knowledge,  what  are  the  most 
efficient  techniques  for  providing  remediation  ? 

Minimum  simulator  capabilities  required  to  begin  assessing  these  problems 
are  summarized  in  Table  8. 

SUMMARY 

Tables  3  through  8  indicate  that  partial  capabilities  for  operator  consoles, 

simulation  control  consoles,  central/distributed  processing  equipment, 

and  own-aircrew  models  are  required  for  all  listed  research  problems. 

These  capabilities  should  therefore  be  developed  early  in  the  simulator 

acquisition  process.  Tactical  situation  models  and  training  support 

functions  are  next  in  terms  of  general  utility.  The  training  support 

functions  related  to  automated  performance  measurement  and 

recordkeeping  would  be  of  particular  value  to  data  collection  in  all  research 

projects  and  should  be  given  high  development  priority  for  that  reason. 

The  remaining  simulation  features,  listed  in  descending  order  of  priority, 

2 

are;  1)  C  communication  network  models;  2)  aerial  combat  tactics 
models;  3)  air  weapons,  sensor  systems,  and  ECM/ECCM  models;  and 
4)  subteam  and  superteam  models.  As  a  summary.  Table  9  lists  the 
simulation  capabilities  in  order  of  priority.  (Level  of  priority  is  based 
on  the  number  of  issues,  as  listed  in  Table  1,  requiring  each  module. ) 
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TABLE  9.  PRIORITIZED  LIST  OF  MAJOR  HARDWARE  AND 

SOFTWARE  MODULES  FOR  PROTOTYPE  RESEARCH/ 
TRAINING  DEVICE 


Module 

Priority 

User  control  consoles 

1  (highest) 

Processing  equipment 

1 

Own- aircrew  models 

1 

Tactical  situation  models 

2 

Training  support  functions 

2 

C  communication  network  model 

i 

Aerial  combat  tactics  models 

4 

Air  weapons  models 

5 

Sensor  system  models 

5 

ECM/ECCM  models 

5 

Subteam  models 

6 

Superteam  models 

6  (lowest) 

If  only  the  top-priority  modules  (from  Table  9)  are  available,  research 
in  the  following  areas  (from  Table  1)  can  begin: 

•  Individual  performance  measurement  (basic  research 
on  performance  measurement) 

•  Media  selection  analyses 

•  Assessment  of  operator  and  team  performance  (research 
on  techniques  for  automated  performance  assessment) 
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If  second-priority  modules  are  added,  research  in  the  following  areas 
can  begin: 

•  Sequencing  of  instructional  material 

•  Definition  of  training  requirements 

•  Physical  fidelity 

•  Automated  operator  and  team  performance  assessment 
(in  simulation  exercises) 

•  Feedback  techniques 

•  Functional  allocation 

•  Operator  and  team  consoles,  communication  nets,  and 
procedures 

•  Maintenance  of  performance  records 

•  Control  of  lesson  and  exercise  sequencing 

•  Adaptive  training  and  testing 

•  Monitoring  and  guidance  of  student  performance 

•  Prerequisite  skill  and  knowledge  requirements 

•  Remediation  techniques 

If  third- priority  modules  are  added,  research  in  the  following  areas  can 
begin: 

•  Interaction  of  team  type  and  task  type  with  instructional  strategy 

•  Part-whole  task  exercises 
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Basic  research  in  team  performance  measurement  techniques  in  the 
2 

AFC“  context  can  begin  if  fourth-priority  modules  are  added. 

If  fifth- priority  modules  are  added,  research  in  the  following  areas 
can  begin: 

•  System  effectiveness  measurement 

•  Contribution  of  individual  and  team  performance  to 
system  effectiveness 

•  Development  of  representative  problem  sets 

•  Tactical  fidelity 

•  Interaction  of  team  type  and  task  type 

Finally,  the  following  topics  can  be  addressed  if  sixth -priority  modules 
are  added: 

•  War  gaming 

•  Information  flow  analysis 

Detailed  research  on  all  topics  will  require  the  complete  set  of  hardware 
and  software  modules. 
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